From jerry.gilliam@sun.com Tue Sep 1 14:26:55 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n81LQtXE023322 for ; Tue, 1 Sep 2009 14:26:55 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n81LQp69055154; Tue, 1 Sep 2009 15:26:53 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPB0050XA8SBA00@brm-avmta-1.central.sun.com>; Tue, 01 Sep 2009 15:26:52 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPB00B8SA8R4JF0@brm-avmta-1.central.sun.com>; Tue, 01 Sep 2009 15:26:52 -0600 (MDT) Received: from [129.146.226.92] (tethys.SFBay.Sun.COM [129.146.226.92]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n81LQpi2993292; Tue, 01 Sep 2009 14:26:51 -0700 (PDT) Date: Tue, 01 Sep 2009 14:22:45 -0700 From: Jerry Gilliam Subject: Re: PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009] To: PSARC-ext@sun.com, Rafael Vanoni Cc: Eric Saxe , Madhavan.Venkataraman@sun.com, Steven Sistare , jerry.gilliam@sun.com Message-id: <4A9D90A5.8030905@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 22096 I am sponsoring the following fast-track on behalf of Rafael Vanoni, with a time-out of 09/09/2009. The project desires minor/major binding, plus micro/patch binding for one interface, as specified. ------------------------------------- Template Version: @(#)onepager.txt 1.35 07/11/07 SMI Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Tickless Kernel Architecture / lbolt decoupling 1.2. Name of Document Author/Supplier: Rafael Vanoni Polanczyk (rafael.vanoni@sun.com) 1.3. Date of This Document: 08/04/09 1.3.1. Date this project was conceived: 07/01/09 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The PAC or CPT you expect to review your project: Solaris PAC 1.4.2. The ARC(s) you expect to review your project: 1.4.3. The Director/VP who is "Sponsoring" this project: Greg.Lavender@Sun.COM 1.4.4. The name of your business unit: Systems 1.5. Email Aliases: 1.5.1. Responsible Manager: darrin.johnson@sun.com 1.5.2. Responsible Engineer: rafael.vanoni@sun.com 1.5.3. Marketing Manger: mike.mulkey@sun.com 1.5.4. Interest List: tickless-dev@opensolaris.org 2. Project Summary 2.1. Project Description: The tickless project aims at implementing the services provided by the clock cyclic in an event driven fashion. The first sub-project is the decoupling of the lbolt and lbolt64 variables from clock(). These two variables are incremented at each firing of the clock cyclic and provide a time reference to the system. They are being replaced by two routines that are backed by gethrtime(), the existing ddi_get_lbolt() and the new ddi_get_lbolt64(), introduced as a migration path for existing non-DDI compliant consumers. This project also presents a solution to minimize the usage of the DDI lbolt routines through new interfaces, and a method to prevent any performance impact of migrating inexpensive references to variables, to calling of routines. These are described in detail on section 4.1. 4. Technical Description: 4.1. Details: lbolt and lbolt64 variables will be replaced by two routines, ddi_get_lbolt() and ddi_get_lbolt64(), which are backed by a hardware counter to provide the same service in en event driven way. One of the major consumers of the lbolt service are the cv_timedwait() and cv_timedwait_sig() routines, which require lbolt to form one of its arguments (an absolute value of time) and once again internally to decompose it into a relative time. This project is introducing two new routines, cv_reltimedwait() and cv_reltimedwait_sig() which will perform the same service of the previously mentioned routines but simply receiving a relative time, and not requiring lbolt at all. These new routines will also have a new argument of type time_res_t to inform the underlying timeout system as to how accurately the given timeout must expire. This will allow the kernel to anticipate or defer such timeouts when possible, allowing the system to stay idle for longer periods of time. Some consumers of the lbolt and lbolt64 variables may have inexplicit dependencies on the cheapness of reading a memory position that will be exposed when migrated to a gethrtime() backed routine. In such cases migrating references to lbolt and lbolt64 to ddi_get_lbolt() and ddi_get_lbolt64() will have a negative performance impact. To address this case, our project will perform the lbolt service in an hybrid way, switching from event to cyclic driven when the DDI lbolt routines are being heavily used. This cyclic mode will reprogram a timer that will expire at each clock tick and increment an internal (lbolt like) variable and return its value to the consumer. This cyclic will only be activated during periods of heavy load, and will switch itself off when the activity subsides. The decision to remove the lbolt and lbolt64 variables was made during design review, and a consensus was reached on the basis that, since we're reaching the end of a major release, this is the right moment to obsolete these. The side effects and cost of maintaining such symbols outweigh the benefits. However, this decision can be re-evaluated in case the negative impact on 3rd party modules during the development release is greater than expected. We're working with ISV and RPE to minimize the impact pro-actively. 4.2. Bug/RFE Number(s): 6860030 tickless clock requires a clock() decoupled lbolt / lbolt64 4.5. Interfaces: This project is adding the following interfaces to the DDI: int64_t ddi_get_lbolt64(void); clock_t cv_reltimedwait(kcondvar_t *cvp, kmutex_t *mp, clock_t delta, time_res_t res); clock_t cv_reltimedwait_sig(kcondvar_t *cvp, kmutex_t *mp, clock_t delta, time_res_t res); With time_res_t defined as enum time_res { TR_NANOSEC, TR_MICROSEC, TR_MILLISEC, TR_SEC, TR_CLOCK_TICK, TR_COUNT }; typedef enum time_res time_res_t; In addition to that, the lbolt and lbolt64 variables (which are *private* symbols known to be used by non-DDI compliant modules) are being removed. 3rd party modules that are not brought up to speed will fail to load. In summary: Interface Commitment Comments ----------------------------------------------------------------------- ddi_get_lbolt64() Public/DDI return lbolt64 cv_reltimedwait(9F) Public/DDI cv_timedwait(9f), relative time cv_reltimedwait_sig(9F) Public/DDI cv_timedwait_sig(9F), relative time lbolt Obsolete commonly referenced kernel symbol lbolt64 Obsolete commonly referenced kernel symbol We also plan on back porting the ddi_get_lbolt64() interface to Solaris 10 Update 9 to extend the migration path for S10 users who would like to update their modules before moving to Solaris Nevada or the next version of Solaris. These users already have ddi_get_lbolt() but currently lack the 64 bits version of it. Such back port will have patch release binding. 4.6. Doc Impact: 6868417 updates for tickless kernel/lbolt decoupling (6860030) Updates to the 'Writing Device Drivers' document are necessary, the project team is in contact with the documentation group to address these. 5. Reference Documents: This project is being developed through OpenSolaris, our project pages and alias contain all the necessary information: http://opensolaris.org/os/project/tickless/ http://opensolaris.org/os/project/tickless/tasks/lbolt/ tickless-dev@opensolaris.org 6. Resources and Schedule: 6.5. ARC review type: Fast track 6.6. ARC Exposure: open Updates to existing man pages: ------------------------------ drv_getparm.9f PARAMETERS ... LBOLT Read the value of lbolt. lbolt is a clock_t that | represents the number of clock ticks since system | boot. No special treatment is applied when | this value overflows the maximum value of the signed integral type clock_t. When this occurs, its value will be negative, and its magnitude will be decreasing until it again passes zero. It can ... drv_hztousec.9f DESCRIPTION The drv_hztousec() function converts into microseconds the time expressed by hertz, which is in system clock ticks. The length of time the system has been up since boot can be | retrieved by calling ddi_get_lbolt(9F), which will return a | value of type clock_t containing the number of clock ticks since boot. Drivers often use this value before and after an I/O request to measure the amount of time it took the device to process the request. The drv_hztousec() function can be used by the driver to convert the reading from clock ticks to a known unit of time. Intro.9f Kernel Functions for Drivers Intro(9F) ddi_get_instance Solaris DDI ddi_get_kt_did Solaris DDI ddi_get_lbolt Solaris DDI ddi_get_lbolt64 Solaris DDI + ddi_get_name Solaris DDI ... Updated ddi_get_lbolt.9f: ------------------------- Kernel Functions for Drivers ddi_get_lbolt(9F) NAME ddi_get_lbolt - returns the number of clock ticks since boot | SYNOPSIS #include #include #include clock_t ddi_get_lbolt(void); INTERFACE LEVEL Solaris DDI specific (Solaris DDI). DESCRIPTION ddi_get_lbolt() returns a value that represents the number | of clock ticks since the system booted. This value is | used as a counter or timer inside the system kernel. The tick frequency can be determined by using drv_usectohz(9F) which converts microseconds into clock ticks. RETURN VALUES ddi_get_lbolt() returns the number of clock ticks since boot | in clock_t type. CONTEXT This routine can be called from any context. SEE ALSO ddi_get_lbolt64(9F), ddi_get_time(9F), drv_getparm(9F), drv_usectohz(9F) New man page for ddi_get_lbolt64(): ----------------------------------- Kernel Functions for Drivers ddi_get_lbolt64(9F) NAME ddi_get_lbolt64 - returns the number of clock ticks since boot in int64_t type SYNOPSIS #include #include #include int64_t ddi_get_lbolt64(void); INTERFACE LEVEL Solaris DDI specific (Solaris DDI). DESCRIPTION ddi_get_lbolt64() returns a value that represents the number of clock ticks since the system booted. This value is used as a counter or timer inside the system kernel. It is essentially the same value returned by ddi_get_lbolt(9F), but in a longer data type that will not wrap for 2.9 billion years. RETURN VALUES ddi_get_lbolt64() returns the number of clock ticks since boot in int64_t type. CONTEXT This routine can be called from any context. SEE ALSO ddi_get_lbolt(9F), ddi_get_time(9F) Writing Device Drivers STREAMS Programming Guide SunOS 5.11 Last change: 29 Jul 2009 1 Updates to condvar(9f): ---------------------- Kernel Functions for Drivers condvar(9F) NAME condvar, cv_init, cv_destroy, cv_wait, cv_signal, cv_broadcast, cv_wait_sig, cv_timedwait, cv_timedwait_sig, cv_reltimedwait, cv_reltimedwait_sig - condition variable routines SYNOPSIS #include void cv_init(kcondvar_t *cvp, char *name, kcv_type_t type, void *arg); void cv_destroy(kcondvar_t *cvp); void cv_wait(kcondvar_t *cvp, kmutex_t *mp); void cv_signal(kcondvar_t *cvp); void cv_broadcast(kcondvar_t *cvp); int cv_wait_sig(kcondvar_t *cvp, kmutex_t *mp); clock_t cv_timedwait(kcondvar_t *cvp, kmutex_t *mp, clock_t timeout); clock_t cv_timedwait_sig(kcondvar_t *cvp, kmutex_t *mp, clock_t timeout); | clock_t cv_reltimedwait(kcondvar_t *cvp, kmutex_t *mp, clock_t delta, | time_res_t resolution); | clock_t cv_reltimedwait_sig(kcondvar_t *cvp, kmutex_t *mp, clock_t delta, | time_res_t resolution); INTERFACE LEVEL Solaris DDI specific (Solaris DDI). PARAMETERS cvp A pointer to an abstract data type kcondvar_t. mp A pointer to a mutual exclusion lock (kmutex_t), initialized by mutex_init(9F) and held by the caller. name Descriptive string. This is obsolete and should be NULL. (Non-NULL strings are legal, but they're a waste of kernel memory.) SunOS 5.11 Last change: 02 Aug 2009 1 Kernel Functions for Drivers condvar(9F) type The constant CV_DRIVER. arg A type-specific argument, drivers should pass arg as NULL. timeout A time, in absolute ticks since boot, when cv_timedwait() or cv_timedwait_sig() should return. | delta A time, in relative ticks, when cv_reltimedwait() | or cv_reltimedwait_sig() should return. | | resolution A flag that specifies how accurately the relative | time interval should be. Possible values are | TR_NANOSEC, TR_MICROSEC, TR_MILLISEC, TR_SEC or | TR_CLOCK_TICK, the former indicating that the interval | should be aligned to system clock ticks. This | information allows the system to anticipate or | deffer the timeout expiration in order to batch process | similarly expiring events. Allowing the system to | stay idle for longer periods of time and enhance | its power efficiency. DESCRIPTION Condition variables are a standard form of thread synchroni- zation. They are designed to be used with mutual exclusion locks (mutexes). The associated mutex is used to ensure that a condition can be checked atomically and that the thread can block on the associated condition variable without miss- ing either a change to the condition or a signal that the condition has changed. Condition variables must be initial- ized by calling cv_init(), and must be deallocated by cal- ling cv_destroy(). The usual use of condition variables is to check a condition (for example, device state, data structure reference count, etc.) while holding a mutex which keeps other threads from changing the condition. If the condition is such that the thread should block, cv_wait() is called with a related con- dition variable and the mutex. At some later point in time, another thread would acquire the mutex, set the condition such that the previous thread can be unblocked, unblock the previous thread with cv_signal() or cv_broadcast(), and then release the mutex. cv_wait() suspends the calling thread and exits the mutex atomically so that another thread which holds the mutex can- not signal on the condition variable until the blocking thread is blocked. Before returning, the mutex is reac- quired. cv_signal() signals the condition and wakes one blocked thread. All blocked threads can be unblocked by calling cv_broadcast(). cv_signal() and cv_broadcast() can be called by a thread even if it does not hold the mutex passed into cv_wait(), though holding the mutex is necessary to ensure predictable scheduling. SunOS 5.11 Last change: 02 Aug 2009 2 Kernel Functions for Drivers condvar(9F) The function cv_wait_sig() is similar to cv_wait() but returns 0 if a signal (for example, by kill(2)) is sent to the thread. In any case, the mutex is reacquired before returning. The function cv_timedwait() is similar to cv_wait(), except that it returns -1 without the condition being signaled after the timeout time has been reached. The function cv_timedwait_sig() is similar to cv_timedwait() and cv_wait_sig(), except that it returns -1 without the condition being signaled after the timeout time has been reached, or 0 if a signal (for example, by kill(2)) is sent to the thread. For both cv_timedwait() and cv_timedwait_sig(), time is in absolute clock ticks since the last system reboot. The current time may be found by calling ddi_get_lbolt(9F). | The cv_reltimedwait() function is similar to cv_timedwait(), | except that it takes a relative time value as argument and | it also takes an additional argument to specify the accuracy | of such interval. cv_reltimedwait_sig() is analogous to | cv_timedwait_sig(), but takes the same arguments as | cv_reltimedwait(). RETURN VALUES 0 For cv_wait_sig(), cv_timedwait_sig() and cv_reltimedwait_sig() indicates that the condition was not necessarily signaled and the function returned because a signal (as in kill(2)) was pending. | -1 For cv_timedwait(), cv_timedwait_sig(), | cv_reltimedwait() and cv_reltimedwait_sig() indicates that the condition was not necessarily signaled and the function returned because the timeout time was reached. | >0 For cv_wait_sig(), cv_timedwait(), cv_timedwait_sig(), | cv_reltimedwait() or cv_reltimedwait_sig() | indicates that the condition was met and the function returned due to a call to cv_signal() or cv_broadcast(), or due to a prema- ture wakeup (see NOTES). CONTEXT These functions can be called from user, kernel or interrupt context. In most cases, however, cv_wait(), cv_timedwait(), | cv_wait_sig(), cv_timedwait_sig(), cv_reltimedwait() and | cv_reltimedwait_sig() should not be called from interrupt context, and cannot be called from a high- level interrupt context. If cv_wait(), cv_timedwait(), cv_wait_sig(), | cv_timedwait_sig(), cv_reltimedwait() or cv_reltimedwait_sig() | are used from interrupt context, lower- SunOS 5.11 Last change: 02 Aug 2009 3 Kernel Functions for Drivers condvar(9F) priority interrupts will not be serviced during the wait. This means that if the thread that will eventually perform the wakeup becomes blocked on anything that requires the lower-priority interrupt, the system will hang. For example, the thread that will perform the wakeup may need to first allocate memory. This memory allocation may require waiting for paging I/O to complete, which may require a lower-priority disk or network interrupt to be serviced. In general, situations like this are hard to predict, so it is advisable to avoid waiting on condition variables or semaphores in an interrupt context. EXAMPLES Example 1 Waiting for a Flag Value in a Driver's Unit Here the condition being waited for is a flag value in a driver's unit structure. The condition variable is also in the unit structure, and the flag word is protected by a mutex in the unit structure. mutex_enter(&un->un_lock); while (un->un_flag & UNIT_BUSY) cv_wait(&un->un_cv, &un->un_lock); un->un_flag |= UNIT_BUSY; mutex_exit(&un->un_lock); Example 2 Unblocking Threads Blocked by the Code in Example 1 At some later point in time, another thread would execute the following to unblock any threads blocked by the above code. mutex_enter(&un->un_lock); un->un_flag &= ~UNIT_BUSY; cv_broadcast(&un->un_cv); mutex_exit(&un->un_lock); NOTES | It is possible for cv_wait(), cv_wait_sig(), cv_timedwait(), | cv_timedwait_sig(), cv_reltimedwait() and cv_reltimedwait_sig() | to return prematurely, that is, not due to a call to cv_signal() or cv_broadcast(). This occurs most commonly in the case of cv_wait_sig(), SunOS 5.11 Last change: 02 Aug 2009 4 Kernel Functions for Drivers condvar(9F) | cv_timedwait_sig() and cv_reltimedwait_sig() when the thread | is stopped and restarted by job control signals or by a debugger, but can happen in other cases as well, even for cv_wait(). Code that calls these functions must always recheck the reason for blocking and call again if the reason for blocking is still true. | If your driver needs to wait on behalf of processes that | have real-time constraints, use cv_timedwait() or cv_reltimedwait() | rather than delay(9F). The delay() function calls timeout(9F), which can be subject to priority inversions. Not all threads can receive signals from user level processes. In cases where such reception is impossible (such as during execution of close(9E) due to exit(2)), cv_wait_sig() behaves as cv_wait(), cv_timedwait_sig() | behaves as cv_timedwait() and cv_reltimedwait_sig() behaves as | cv_reltimedwait(). To avoid unkillable processes, users of these functions may need to protect against waiting indefinitely for events that might not occur. The ddi_can_receive_sig(9F) function is provided to detect when signal reception is possible. SEE ALSO kill(2), ddi_can_receive_sig(9F), ddi_get_lbolt(9F), | ddi_get_lbolt64(9F), mutex(9F), mutex_init(9F) Writing Device Drivers SunOS 5.11 Last change: 02 Aug 2009 5 From gdamore@sun.com Tue Sep 1 14:40:21 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n81LeKjZ023671 for ; Tue, 1 Sep 2009 14:40:20 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n81LeHoD026059 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Sep 2009 05:40:19 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPB00007AV5XL00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 01 Sep 2009 14:40:17 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPB00DDQAV5D580@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 01 Sep 2009 14:40:17 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n81LeHT0020060 for ; Tue, 01 Sep 2009 14:40:17 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPB00H009I1QW00@fe-sfbay-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 01 Sep 2009 14:40:17 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPB00HY0AV1L1A0@fe-sfbay-09.sun.com>; Tue, 01 Sep 2009 14:40:14 -0700 (PDT) Date: Tue, 01 Sep 2009 14:40:13 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009] In-reply-to: <4A9D90A5.8030905@sun.com> Sender: Garrett.Damore@sun.com To: Jerry Gilliam Cc: PSARC-ext@sun.com, Rafael Vanoni , Eric Saxe , Madhavan.Venkataraman@sun.com, Steven Sistare Message-id: <4A9D94BD.8040000@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A9D90A5.8030905@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 24110 I'm inclined to give this a +1, but I'm also concerned that the changes here, while *good*, may exceed the scope of a fast track. I'm close to derailing, only to ensure that the case is properly reviewed. This is not something that we should have slip in under the radar, even if I think the changes are all *good*. :-) If any other member is in agreement with me, let me know, and I'll derail it. I'm happy to own the case and the opinion duties. :-) If however, everyone else feels that this should be left as a fast track, then I'll leave it alone. I certainly don't have any particular problem with the case as specified, beyond the minor issues pointed out below. Other considerations: 1) I don't see any changes made to cv_wait and cv_timedwait. Does it make sense to obsolete them at the same time that we're introducing cv_reltimedwait()? 2) for enum time_res, it might be convenient to use shorter names, using SI abbreviations. I'd suggest: enum time_res { TR_NSEC, TR_USEC, TR_MSEC, TR_SEC, TR_TICK, TR_COUNT }; (Btw, what is the difference between TR_COUNT and TR_CLOCK_TICK?) - Garrett Jerry Gilliam wrote: > > I am sponsoring the following fast-track on behalf of Rafael Vanoni, > with a time-out of 09/09/2009. The project desires > minor/major binding, plus micro/patch binding for one > interface, as specified. > > ------------------------------------- > > Template Version: @(#)onepager.txt 1.35 07/11/07 SMI > Copyright 2007 Sun Microsystems > > 1. Introduction > 1.1. Project/Component Working Name: > Tickless Kernel Architecture / lbolt decoupling > > 1.2. Name of Document Author/Supplier: > Rafael Vanoni Polanczyk (rafael.vanoni@sun.com) > > 1.3. Date of This Document: > 08/04/09 > > 1.3.1. Date this project was conceived: > 07/01/09 > > 1.4. Name of Major Document Customer(s)/Consumer(s): > 1.4.1. The PAC or CPT you expect to review your project: > Solaris PAC > 1.4.2. The ARC(s) you expect to review your project: > 1.4.3. The Director/VP who is "Sponsoring" this project: > Greg.Lavender@Sun.COM > 1.4.4. The name of your business unit: > Systems > > 1.5. Email Aliases: > 1.5.1. Responsible Manager: darrin.johnson@sun.com > 1.5.2. Responsible Engineer: rafael.vanoni@sun.com > 1.5.3. Marketing Manger: mike.mulkey@sun.com > 1.5.4. Interest List: tickless-dev@opensolaris.org > > > 2. Project Summary > 2.1. Project Description: > The tickless project aims at implementing the services provided > by the > clock cyclic in an event driven fashion. The first sub-project > is the > decoupling of the lbolt and lbolt64 variables from clock(). > These two > variables are incremented at each firing of the clock cyclic > and provide > a time reference to the system. They are being replaced by two > routines > that are backed by gethrtime(), the existing ddi_get_lbolt() and > the new ddi_get_lbolt64(), introduced as a migration path for > existing > non-DDI compliant consumers. > > This project also presents a solution to minimize the usage of > the DDI > lbolt routines through new interfaces, and a method to prevent any > performance impact of migrating inexpensive references to > variables, to > calling of routines. These are described in detail on section 4.1. > > > 4. Technical Description: > 4.1. Details: > lbolt and lbolt64 variables will be replaced by two routines, > ddi_get_lbolt() and ddi_get_lbolt64(), which are backed by a hardware > counter to provide the same service in en event driven way. > > One of the major consumers of the lbolt service are the > cv_timedwait() > and cv_timedwait_sig() routines, which require lbolt to form > one of its > arguments (an absolute value of time) and once again internally to > decompose it into a relative time. This project is introducing > two new > routines, cv_reltimedwait() and cv_reltimedwait_sig() which > will perform > the same service of the previously mentioned routines but simply > receiving a relative time, and not requiring lbolt at all. > These new > routines will also have a new argument of type time_res_t to > inform > the underlying timeout system as to how accurately the given > timeout > must expire. This will allow the kernel to anticipate or defer > such > timeouts when possible, allowing the system to stay idle for > longer > periods of time. > > Some consumers of the lbolt and lbolt64 variables may have > inexplicit > dependencies on the cheapness of reading a memory position that > will be > exposed when migrated to a gethrtime() backed routine. In such > cases > migrating references to lbolt and lbolt64 to ddi_get_lbolt() and > ddi_get_lbolt64() will have a negative performance impact. To > address > this case, our project will perform the lbolt service in an > hybrid way, > switching from event to cyclic driven when the DDI lbolt > routines are > being heavily used. This cyclic mode will reprogram a timer > that will > expire at each clock tick and increment an internal (lbolt > like) > variable and return its value to the consumer. This cyclic will > only > be activated during periods of heavy load, and will switch > itself off > when the activity subsides. > > The decision to remove the lbolt and lbolt64 variables was made > during > design review, and a consensus was reached on the basis that, since > we're reaching the end of a major release, this is the right > moment to > obsolete these. The side effects and cost of maintaining such symbols > outweigh the benefits. However, this decision can be re-evaluated in > case the negative impact on 3rd party modules during the development > release is greater than expected. We're working with ISV and RPE to > minimize the impact pro-actively. > > 4.2. Bug/RFE Number(s): > 6860030 tickless clock requires a clock() decoupled lbolt / > lbolt64 > > 4.5. Interfaces: > This project is adding the following interfaces to the DDI: > > int64_t ddi_get_lbolt64(void); > > clock_t cv_reltimedwait(kcondvar_t *cvp, kmutex_t *mp, clock_t > delta, > time_res_t res); > > clock_t cv_reltimedwait_sig(kcondvar_t *cvp, kmutex_t *mp, > clock_t > delta, time_res_t res); > > With time_res_t defined as > > enum time_res { > TR_NANOSEC, > TR_MICROSEC, > TR_MILLISEC, > TR_SEC, > TR_CLOCK_TICK, > TR_COUNT > }; > > typedef enum time_res time_res_t; > > In addition to that, the lbolt and lbolt64 variables (which are > *private* symbols known to be used by non-DDI compliant > modules) are > being removed. 3rd party modules that are not brought up to > speed will > fail to load. > > In summary: > > Interface Commitment Comments > > ----------------------------------------------------------------------- > ddi_get_lbolt64() Public/DDI return lbolt64 > cv_reltimedwait(9F) Public/DDI cv_timedwait(9f), relative time > cv_reltimedwait_sig(9F) Public/DDI cv_timedwait_sig(9F), > relative time > lbolt Obsolete commonly referenced kernel symbol > lbolt64 Obsolete commonly referenced kernel symbol > > We also plan on back porting the ddi_get_lbolt64() interface to > Solaris > 10 Update 9 to extend the migration path for S10 users who would like > to update their modules before moving to Solaris Nevada or the next > version of Solaris. These users already have ddi_get_lbolt() but > currently lack the 64 bits version of it. Such back port will have > patch release binding. > > > 4.6. Doc Impact: > 6868417 updates for tickless kernel/lbolt decoupling (6860030) > > Updates to the 'Writing Device Drivers' document are > necessary, the > project team is in contact with the documentation group to > address > these. > > > 5. Reference Documents: > This project is being developed through OpenSolaris, our project > pages > and alias contain all the necessary information: > http://opensolaris.org/os/project/tickless/ > http://opensolaris.org/os/project/tickless/tasks/lbolt/ > tickless-dev@opensolaris.org > > > 6. Resources and Schedule: > 6.5. ARC review type: Fast track > 6.6. ARC Exposure: open > > > > > > Updates to existing man pages: > ------------------------------ > > drv_getparm.9f > > PARAMETERS > ... > > LBOLT Read the value of lbolt. lbolt is a clock_t that | > represents the number of clock ticks since system | > boot. No special treatment is applied when | > this value overflows the maximum value of the > signed integral type clock_t. When this occurs, > its value will be negative, and its magnitude will > be decreasing until it again passes zero. It can > ... > > > > > drv_hztousec.9f > > DESCRIPTION > The drv_hztousec() function converts into microseconds the > time expressed by hertz, which is in system clock ticks. > > The length of time the system has been up since boot can be | > retrieved by calling ddi_get_lbolt(9F), which will return a | > value of type clock_t containing the number of clock ticks > since boot. Drivers often use this value before and after an > I/O request to measure the amount of time it took the device to > process the request. The drv_hztousec() function can be used > by the driver to convert the reading from clock ticks to a > known unit of time. > > > > > Intro.9f > > Kernel Functions for Drivers Intro(9F) > > ddi_get_instance Solaris DDI > ddi_get_kt_did Solaris DDI > ddi_get_lbolt Solaris DDI > ddi_get_lbolt64 Solaris DDI + > ddi_get_name Solaris DDI > ... > > > > > Updated ddi_get_lbolt.9f: > ------------------------- > > Kernel Functions for Drivers ddi_get_lbolt(9F) > > NAME > ddi_get_lbolt - returns the number of clock ticks since boot | > > SYNOPSIS > #include > #include > #include > > clock_t ddi_get_lbolt(void); > > INTERFACE LEVEL > Solaris DDI specific (Solaris DDI). > > DESCRIPTION > ddi_get_lbolt() returns a value that represents the number | > of clock ticks since the system booted. This value is | > used as a counter or timer inside the system kernel. > The tick frequency can be determined by using drv_usectohz(9F) > which converts microseconds into clock ticks. > > > RETURN VALUES > ddi_get_lbolt() returns the number of clock ticks since boot | > in clock_t type. > > CONTEXT > This routine can be called from any context. > > SEE ALSO > ddi_get_lbolt64(9F), ddi_get_time(9F), drv_getparm(9F), > drv_usectohz(9F) > > > > > New man page for ddi_get_lbolt64(): > ----------------------------------- > > Kernel Functions for Drivers ddi_get_lbolt64(9F) > > NAME > ddi_get_lbolt64 - returns the number of clock ticks since boot > in int64_t type > > SYNOPSIS > #include > #include > #include > > int64_t ddi_get_lbolt64(void); > > INTERFACE LEVEL > Solaris DDI specific (Solaris DDI). > > DESCRIPTION > ddi_get_lbolt64() returns a value that represents the number > of clock ticks since the system booted. This value is > used as a counter or timer inside the system kernel. It is > essentially the same value returned by ddi_get_lbolt(9F), but in a > longer data type that will not wrap for 2.9 billion years. > > RETURN VALUES > ddi_get_lbolt64() returns the number of clock ticks since boot > in int64_t type. > > CONTEXT > This routine can be called from any context. > > SEE ALSO > ddi_get_lbolt(9F), ddi_get_time(9F) > > Writing Device Drivers > > STREAMS Programming Guide > > SunOS 5.11 Last change: 29 Jul 2009 1 > > > Updates to condvar(9f): > ---------------------- > > Kernel Functions for Drivers condvar(9F) > > NAME > condvar, cv_init, cv_destroy, cv_wait, cv_signal, > cv_broadcast, cv_wait_sig, cv_timedwait, cv_timedwait_sig, > cv_reltimedwait, cv_reltimedwait_sig - condition variable > routines > > SYNOPSIS > #include > > void cv_init(kcondvar_t *cvp, char *name, kcv_type_t type, void > *arg); > > void cv_destroy(kcondvar_t *cvp); > > void cv_wait(kcondvar_t *cvp, kmutex_t *mp); > > void cv_signal(kcondvar_t *cvp); > > void cv_broadcast(kcondvar_t *cvp); > > int cv_wait_sig(kcondvar_t *cvp, kmutex_t *mp); > > clock_t cv_timedwait(kcondvar_t *cvp, kmutex_t *mp, clock_t > timeout); > > clock_t cv_timedwait_sig(kcondvar_t *cvp, kmutex_t *mp, clock_t > timeout); > > | clock_t cv_reltimedwait(kcondvar_t *cvp, kmutex_t *mp, clock_t > delta, > | time_res_t resolution); > > | clock_t cv_reltimedwait_sig(kcondvar_t *cvp, kmutex_t *mp, > clock_t delta, > | time_res_t resolution); > > INTERFACE LEVEL > Solaris DDI specific (Solaris DDI). > > PARAMETERS > cvp A pointer to an abstract data type kcondvar_t. > > mp A pointer to a mutual exclusion lock (kmutex_t), > initialized by mutex_init(9F) and held by the > caller. > > name Descriptive string. This is obsolete and should > be NULL. (Non-NULL strings are legal, but they're > a waste of kernel memory.) > > SunOS 5.11 Last change: 02 Aug 2009 1 > > Kernel Functions for Drivers condvar(9F) > > type The constant CV_DRIVER. > > arg A type-specific argument, drivers should pass arg > as NULL. > > timeout A time, in absolute ticks since boot, when > cv_timedwait() or cv_timedwait_sig() should > return. > > | delta A time, in relative ticks, when cv_reltimedwait() > | or cv_reltimedwait_sig() should return. > | > | resolution A flag that specifies how accurately the relative > | time interval should be. Possible values are > | TR_NANOSEC, TR_MICROSEC, TR_MILLISEC, TR_SEC or > | TR_CLOCK_TICK, the former indicating that the interval > | should be aligned to system clock ticks. This > | information allows the system to anticipate or > | deffer the timeout expiration in order to batch process > | similarly expiring events. Allowing the system to > | stay idle for longer periods of time and enhance > | its power efficiency. > > > DESCRIPTION > Condition variables are a standard form of thread synchroni- > zation. They are designed to be used with mutual exclusion > locks (mutexes). The associated mutex is used to ensure that > a condition can be checked atomically and that the thread > can block on the associated condition variable without miss- > ing either a change to the condition or a signal that the > condition has changed. Condition variables must be initial- > ized by calling cv_init(), and must be deallocated by cal- > ling cv_destroy(). > > The usual use of condition variables is to check a condition > (for example, device state, data structure reference count, > etc.) while holding a mutex which keeps other threads from > changing the condition. If the condition is such that the > thread should block, cv_wait() is called with a related con- > dition variable and the mutex. At some later point in time, > another thread would acquire the mutex, set the condition > such that the previous thread can be unblocked, unblock the > previous thread with cv_signal() or cv_broadcast(), and then > release the mutex. > > cv_wait() suspends the calling thread and exits the mutex > atomically so that another thread which holds the mutex can- > not signal on the condition variable until the blocking > thread is blocked. Before returning, the mutex is reac- > quired. > > cv_signal() signals the condition and wakes one blocked > thread. All blocked threads can be unblocked by calling > cv_broadcast(). cv_signal() and cv_broadcast() can be called > by a thread even if it does not hold the mutex passed into > cv_wait(), though holding the mutex is necessary to ensure > predictable scheduling. > > SunOS 5.11 Last change: 02 Aug 2009 2 > > Kernel Functions for Drivers condvar(9F) > > The function cv_wait_sig() is similar to cv_wait() but > returns 0 if a signal (for example, by kill(2)) is sent to > the thread. In any case, the mutex is reacquired before > returning. > > The function cv_timedwait() is similar to cv_wait(), except > that it returns -1 without the condition being signaled > after the timeout time has been reached. > > The function cv_timedwait_sig() is similar to cv_timedwait() > and cv_wait_sig(), except that it returns -1 without the > condition being signaled after the timeout time has been > reached, or 0 if a signal (for example, by kill(2)) is sent > to the thread. > > For both cv_timedwait() and cv_timedwait_sig(), time is in > absolute clock ticks since the last system reboot. The > current time may be found by calling ddi_get_lbolt(9F). > > | The cv_reltimedwait() function is similar to cv_timedwait(), > | except that it takes a relative time value as argument and > | it also takes an additional argument to specify the accuracy > | of such interval. cv_reltimedwait_sig() is analogous to > | cv_timedwait_sig(), but takes the same arguments as > | cv_reltimedwait(). > > RETURN VALUES > 0 For cv_wait_sig(), cv_timedwait_sig() and > cv_reltimedwait_sig() > indicates > that the condition was not necessarily signaled and > the function returned because a signal (as in > kill(2)) was pending. > > | -1 For cv_timedwait(), cv_timedwait_sig(), > | cv_reltimedwait() and cv_reltimedwait_sig() indicates > that the condition was not necessarily signaled and > the function returned because the timeout time was > reached. > > | >0 For cv_wait_sig(), cv_timedwait(), cv_timedwait_sig(), > | cv_reltimedwait() or cv_reltimedwait_sig() > | indicates that the condition was > met and the function returned due to a call to > cv_signal() or cv_broadcast(), or due to a prema- > ture wakeup (see NOTES). > > CONTEXT > These functions can be called from user, kernel or interrupt > context. In most cases, however, cv_wait(), cv_timedwait(), > | cv_wait_sig(), cv_timedwait_sig(), cv_reltimedwait() and > | cv_reltimedwait_sig() > should not be called > from interrupt context, and cannot be called from a high- > level interrupt context. > > If cv_wait(), cv_timedwait(), cv_wait_sig(), > | cv_timedwait_sig(), cv_reltimedwait() or cv_reltimedwait_sig() > | are used from interrupt context, lower- > > SunOS 5.11 Last change: 02 Aug 2009 3 > > Kernel Functions for Drivers condvar(9F) > > priority interrupts will not be serviced during the wait. > This means that if the thread that will eventually perform > the wakeup becomes blocked on anything that requires the > lower-priority interrupt, the system will hang. > > For example, the thread that will perform the wakeup may > need to first allocate memory. This memory allocation may > require waiting for paging I/O to complete, which may > require a lower-priority disk or network interrupt to be > serviced. In general, situations like this are hard to > predict, so it is advisable to avoid waiting on condition > variables or semaphores in an interrupt context. > > EXAMPLES > Example 1 Waiting for a Flag Value in a Driver's Unit > > Here the condition being waited for is a flag value in a > driver's unit structure. The condition variable is also in > the unit structure, and the flag word is protected by a > mutex in the unit structure. > > mutex_enter(&un->un_lock); > while (un->un_flag & UNIT_BUSY) > cv_wait(&un->un_cv, &un->un_lock); > un->un_flag |= UNIT_BUSY; > mutex_exit(&un->un_lock); > > Example 2 Unblocking Threads Blocked by the Code in Example > 1 > > At some later point in time, another thread would execute > the following to unblock any threads blocked by the above > code. > > mutex_enter(&un->un_lock); > un->un_flag &= ~UNIT_BUSY; > cv_broadcast(&un->un_cv); > mutex_exit(&un->un_lock); > > NOTES > | It is possible for cv_wait(), cv_wait_sig(), cv_timedwait(), > | cv_timedwait_sig(), cv_reltimedwait() and cv_reltimedwait_sig() > | to return prematurely, that is, not > due to a call to cv_signal() or cv_broadcast(). This occurs > most commonly in the case of cv_wait_sig(), > > SunOS 5.11 Last change: 02 Aug 2009 4 > > Kernel Functions for Drivers condvar(9F) > > | cv_timedwait_sig() and cv_reltimedwait_sig() when the thread > | is stopped and restarted > by job control signals or by a debugger, but can happen in > other cases as well, even for cv_wait(). Code that calls > these functions must always recheck the reason for blocking > and call again if the reason for blocking is still true. > > | If your driver needs to wait on behalf of processes that > | have real-time constraints, use cv_timedwait() or > cv_reltimedwait() > | rather than > delay(9F). The delay() function calls timeout(9F), which can > be subject to priority inversions. > > Not all threads can receive signals from user level > processes. In cases where such reception is impossible (such > as during execution of close(9E) due to exit(2)), > cv_wait_sig() behaves as cv_wait(), cv_timedwait_sig() > | behaves as cv_timedwait() and cv_reltimedwait_sig() behaves as > | cv_reltimedwait(). > To avoid unkillable processes, > users of these functions may need to protect against waiting > indefinitely for events that might not occur. The > ddi_can_receive_sig(9F) function is provided to detect when > signal reception is possible. > > SEE ALSO > kill(2), ddi_can_receive_sig(9F), ddi_get_lbolt(9F), > | ddi_get_lbolt64(9F), mutex(9F), mutex_init(9F) > > Writing Device Drivers > > SunOS 5.11 Last change: 02 Aug 2009 5 > From Rafael.Vanoni@sun.com Tue Sep 1 14:47:14 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n81LlEWJ023875 for ; Tue, 1 Sep 2009 14:47:14 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n81Ll7Ht017713 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 1 Sep 2009 22:47:13 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPB00K1XB6N3E00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 01 Sep 2009 14:47:11 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPB0084MB6MSAF0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 01 Sep 2009 14:47:10 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n81LlAkj015458 for ; Tue, 01 Sep 2009 14:47:10 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPB00700AZBDK00@fe-sfbay-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 01 Sep 2009 14:47:10 -0700 (PDT) Received: from [129.146.229.172] ([unknown] [129.146.229.172]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPB006MLB6FPE10@fe-sfbay-10.sun.com>; Tue, 01 Sep 2009 14:47:04 -0700 (PDT) Date: Tue, 01 Sep 2009 14:47:03 -0700 From: Rafael Vanoni Subject: Re: PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009] In-reply-to: <4A9D94BD.8040000@sun.com> Sender: Rafael.Vanoni@sun.com To: "Garrett D'Amore" Cc: Jerry Gilliam , PSARC-ext@sun.com, Eric Saxe , Madhavan.Venkataraman@sun.com, Steven Sistare Message-id: <4A9D9657.9010104@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A9D90A5.8030905@sun.com> <4A9D94BD.8040000@sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090804) Status: RO Content-Length: 25205 Hi Garret Garrett D'Amore wrote: > I'm inclined to give this a +1, but I'm also concerned that the changes > here, while *good*, may exceed the scope of a fast track. I'm close to > derailing, only to ensure that the case is properly reviewed. This is > not something that we should have slip in under the radar, even if I > think the changes are all *good*. :-) > > If any other member is in agreement with me, let me know, and I'll > derail it. I'm happy to own the case and the opinion duties. :-) If > however, everyone else feels that this should be left as a fast track, > then I'll leave it alone. I certainly don't have any particular problem > with the case as specified, beyond the minor issues pointed out below. > > Other considerations: > > 1) I don't see any changes made to cv_wait and cv_timedwait. Does it > make sense to obsolete them at the same time that we're introducing > cv_reltimedwait()? There are still many consumers of cv_timedwait who need to pass in an absolute time. cv_wait serves a similar purpose but without the timed component, so it's functionality doesn't overlap with cv_reltimedwait(). > 2) for enum time_res, it might be convenient to use shorter names, using > SI abbreviations. I'd suggest: > > enum time_res { > TR_NSEC, > TR_USEC, > TR_MSEC, > TR_SEC, > TR_TICK, > TR_COUNT > }; > > (Btw, what is the difference between TR_COUNT and TR_CLOCK_TICK?) TR_CLOCK_TICK represents the duration of a clock tick in nanoseconds (nsec_per_tick). TR_COUNT is simply the number of elements in the enumeration. Thanks, Rafael > - Garrett > > Jerry Gilliam wrote: >> >> I am sponsoring the following fast-track on behalf of Rafael Vanoni, >> with a time-out of 09/09/2009. The project desires >> minor/major binding, plus micro/patch binding for one >> interface, as specified. >> >> ------------------------------------- >> >> Template Version: @(#)onepager.txt 1.35 07/11/07 SMI >> Copyright 2007 Sun Microsystems >> >> 1. Introduction >> 1.1. Project/Component Working Name: >> Tickless Kernel Architecture / lbolt decoupling >> >> 1.2. Name of Document Author/Supplier: >> Rafael Vanoni Polanczyk (rafael.vanoni@sun.com) >> >> 1.3. Date of This Document: >> 08/04/09 >> >> 1.3.1. Date this project was conceived: >> 07/01/09 >> >> 1.4. Name of Major Document Customer(s)/Consumer(s): >> 1.4.1. The PAC or CPT you expect to review your project: >> Solaris PAC >> 1.4.2. The ARC(s) you expect to review your project: >> 1.4.3. The Director/VP who is "Sponsoring" this project: >> Greg.Lavender@Sun.COM >> 1.4.4. The name of your business unit: >> Systems >> >> 1.5. Email Aliases: >> 1.5.1. Responsible Manager: darrin.johnson@sun.com >> 1.5.2. Responsible Engineer: rafael.vanoni@sun.com >> 1.5.3. Marketing Manger: mike.mulkey@sun.com >> 1.5.4. Interest List: tickless-dev@opensolaris.org >> >> >> 2. Project Summary >> 2.1. Project Description: >> The tickless project aims at implementing the services provided >> by the >> clock cyclic in an event driven fashion. The first sub-project >> is the >> decoupling of the lbolt and lbolt64 variables from clock(). >> These two >> variables are incremented at each firing of the clock cyclic >> and provide >> a time reference to the system. They are being replaced by two >> routines >> that are backed by gethrtime(), the existing ddi_get_lbolt() and >> the new ddi_get_lbolt64(), introduced as a migration path for >> existing >> non-DDI compliant consumers. >> >> This project also presents a solution to minimize the usage of >> the DDI >> lbolt routines through new interfaces, and a method to prevent any >> performance impact of migrating inexpensive references to >> variables, to >> calling of routines. These are described in detail on section 4.1. >> >> >> 4. Technical Description: >> 4.1. Details: >> lbolt and lbolt64 variables will be replaced by two routines, >> ddi_get_lbolt() and ddi_get_lbolt64(), which are backed by a hardware >> counter to provide the same service in en event driven way. >> >> One of the major consumers of the lbolt service are the >> cv_timedwait() >> and cv_timedwait_sig() routines, which require lbolt to form >> one of its >> arguments (an absolute value of time) and once again internally to >> decompose it into a relative time. This project is introducing >> two new >> routines, cv_reltimedwait() and cv_reltimedwait_sig() which >> will perform >> the same service of the previously mentioned routines but simply >> receiving a relative time, and not requiring lbolt at all. >> These new >> routines will also have a new argument of type time_res_t to >> inform >> the underlying timeout system as to how accurately the given >> timeout >> must expire. This will allow the kernel to anticipate or defer >> such >> timeouts when possible, allowing the system to stay idle for >> longer >> periods of time. >> >> Some consumers of the lbolt and lbolt64 variables may have >> inexplicit >> dependencies on the cheapness of reading a memory position that >> will be >> exposed when migrated to a gethrtime() backed routine. In such >> cases >> migrating references to lbolt and lbolt64 to ddi_get_lbolt() and >> ddi_get_lbolt64() will have a negative performance impact. To >> address >> this case, our project will perform the lbolt service in an >> hybrid way, >> switching from event to cyclic driven when the DDI lbolt >> routines are >> being heavily used. This cyclic mode will reprogram a timer >> that will >> expire at each clock tick and increment an internal (lbolt >> like) >> variable and return its value to the consumer. This cyclic will >> only >> be activated during periods of heavy load, and will switch >> itself off >> when the activity subsides. >> >> The decision to remove the lbolt and lbolt64 variables was made >> during >> design review, and a consensus was reached on the basis that, since >> we're reaching the end of a major release, this is the right >> moment to >> obsolete these. The side effects and cost of maintaining such symbols >> outweigh the benefits. However, this decision can be re-evaluated in >> case the negative impact on 3rd party modules during the development >> release is greater than expected. We're working with ISV and RPE to >> minimize the impact pro-actively. >> >> 4.2. Bug/RFE Number(s): >> 6860030 tickless clock requires a clock() decoupled lbolt / >> lbolt64 >> >> 4.5. Interfaces: >> This project is adding the following interfaces to the DDI: >> >> int64_t ddi_get_lbolt64(void); >> >> clock_t cv_reltimedwait(kcondvar_t *cvp, kmutex_t *mp, clock_t >> delta, >> time_res_t res); >> >> clock_t cv_reltimedwait_sig(kcondvar_t *cvp, kmutex_t *mp, >> clock_t >> delta, time_res_t res); >> >> With time_res_t defined as >> >> enum time_res { >> TR_NANOSEC, >> TR_MICROSEC, >> TR_MILLISEC, >> TR_SEC, >> TR_CLOCK_TICK, >> TR_COUNT >> }; >> >> typedef enum time_res time_res_t; >> >> In addition to that, the lbolt and lbolt64 variables (which are >> *private* symbols known to be used by non-DDI compliant >> modules) are >> being removed. 3rd party modules that are not brought up to >> speed will >> fail to load. >> >> In summary: >> >> Interface Commitment Comments >> >> ----------------------------------------------------------------------- >> ddi_get_lbolt64() Public/DDI return lbolt64 >> cv_reltimedwait(9F) Public/DDI cv_timedwait(9f), relative time >> cv_reltimedwait_sig(9F) Public/DDI cv_timedwait_sig(9F), >> relative time >> lbolt Obsolete commonly referenced kernel symbol >> lbolt64 Obsolete commonly referenced kernel symbol >> >> We also plan on back porting the ddi_get_lbolt64() interface to >> Solaris >> 10 Update 9 to extend the migration path for S10 users who would like >> to update their modules before moving to Solaris Nevada or the next >> version of Solaris. These users already have ddi_get_lbolt() but >> currently lack the 64 bits version of it. Such back port will have >> patch release binding. >> >> >> 4.6. Doc Impact: >> 6868417 updates for tickless kernel/lbolt decoupling (6860030) >> >> Updates to the 'Writing Device Drivers' document are >> necessary, the >> project team is in contact with the documentation group to >> address >> these. >> >> >> 5. Reference Documents: >> This project is being developed through OpenSolaris, our project >> pages >> and alias contain all the necessary information: >> http://opensolaris.org/os/project/tickless/ >> http://opensolaris.org/os/project/tickless/tasks/lbolt/ >> tickless-dev@opensolaris.org >> >> >> 6. Resources and Schedule: >> 6.5. ARC review type: Fast track >> 6.6. ARC Exposure: open >> >> >> >> >> >> Updates to existing man pages: >> ------------------------------ >> >> drv_getparm.9f >> >> PARAMETERS >> ... >> >> LBOLT Read the value of lbolt. lbolt is a clock_t that | >> represents the number of clock ticks since system | >> boot. No special treatment is applied when | >> this value overflows the maximum value of the >> signed integral type clock_t. When this occurs, >> its value will be negative, and its magnitude will >> be decreasing until it again passes zero. It can >> ... >> >> >> >> >> drv_hztousec.9f >> >> DESCRIPTION >> The drv_hztousec() function converts into microseconds the >> time expressed by hertz, which is in system clock ticks. >> >> The length of time the system has been up since boot can be | >> retrieved by calling ddi_get_lbolt(9F), which will return a | >> value of type clock_t containing the number of clock ticks >> since boot. Drivers often use this value before and after an >> I/O request to measure the amount of time it took the device to >> process the request. The drv_hztousec() function can be used >> by the driver to convert the reading from clock ticks to a >> known unit of time. >> >> >> >> >> Intro.9f >> >> Kernel Functions for Drivers Intro(9F) >> >> ddi_get_instance Solaris DDI >> ddi_get_kt_did Solaris DDI >> ddi_get_lbolt Solaris DDI >> ddi_get_lbolt64 Solaris DDI + >> ddi_get_name Solaris DDI >> ... >> >> >> >> >> Updated ddi_get_lbolt.9f: >> ------------------------- >> >> Kernel Functions for Drivers ddi_get_lbolt(9F) >> >> NAME >> ddi_get_lbolt - returns the number of clock ticks since boot | >> >> SYNOPSIS >> #include >> #include >> #include >> >> clock_t ddi_get_lbolt(void); >> >> INTERFACE LEVEL >> Solaris DDI specific (Solaris DDI). >> >> DESCRIPTION >> ddi_get_lbolt() returns a value that represents the number | >> of clock ticks since the system booted. This value is | >> used as a counter or timer inside the system kernel. >> The tick frequency can be determined by using drv_usectohz(9F) >> which converts microseconds into clock ticks. >> >> >> RETURN VALUES >> ddi_get_lbolt() returns the number of clock ticks since boot | >> in clock_t type. >> >> CONTEXT >> This routine can be called from any context. >> >> SEE ALSO >> ddi_get_lbolt64(9F), ddi_get_time(9F), drv_getparm(9F), >> drv_usectohz(9F) >> >> >> >> >> New man page for ddi_get_lbolt64(): >> ----------------------------------- >> >> Kernel Functions for Drivers ddi_get_lbolt64(9F) >> >> NAME >> ddi_get_lbolt64 - returns the number of clock ticks since boot >> in int64_t type >> >> SYNOPSIS >> #include >> #include >> #include >> >> int64_t ddi_get_lbolt64(void); >> >> INTERFACE LEVEL >> Solaris DDI specific (Solaris DDI). >> >> DESCRIPTION >> ddi_get_lbolt64() returns a value that represents the number >> of clock ticks since the system booted. This value is >> used as a counter or timer inside the system kernel. It is >> essentially the same value returned by ddi_get_lbolt(9F), but in a >> longer data type that will not wrap for 2.9 billion years. >> >> RETURN VALUES >> ddi_get_lbolt64() returns the number of clock ticks since boot >> in int64_t type. >> >> CONTEXT >> This routine can be called from any context. >> >> SEE ALSO >> ddi_get_lbolt(9F), ddi_get_time(9F) >> >> Writing Device Drivers >> >> STREAMS Programming Guide >> >> SunOS 5.11 Last change: 29 Jul 2009 1 >> >> >> Updates to condvar(9f): >> ---------------------- >> >> Kernel Functions for Drivers condvar(9F) >> >> NAME >> condvar, cv_init, cv_destroy, cv_wait, cv_signal, >> cv_broadcast, cv_wait_sig, cv_timedwait, cv_timedwait_sig, >> cv_reltimedwait, cv_reltimedwait_sig - condition variable >> routines >> >> SYNOPSIS >> #include >> >> void cv_init(kcondvar_t *cvp, char *name, kcv_type_t type, void >> *arg); >> >> void cv_destroy(kcondvar_t *cvp); >> >> void cv_wait(kcondvar_t *cvp, kmutex_t *mp); >> >> void cv_signal(kcondvar_t *cvp); >> >> void cv_broadcast(kcondvar_t *cvp); >> >> int cv_wait_sig(kcondvar_t *cvp, kmutex_t *mp); >> >> clock_t cv_timedwait(kcondvar_t *cvp, kmutex_t *mp, clock_t >> timeout); >> >> clock_t cv_timedwait_sig(kcondvar_t *cvp, kmutex_t *mp, clock_t >> timeout); >> >> | clock_t cv_reltimedwait(kcondvar_t *cvp, kmutex_t *mp, clock_t >> delta, >> | time_res_t resolution); >> >> | clock_t cv_reltimedwait_sig(kcondvar_t *cvp, kmutex_t *mp, >> clock_t delta, >> | time_res_t resolution); >> >> INTERFACE LEVEL >> Solaris DDI specific (Solaris DDI). >> >> PARAMETERS >> cvp A pointer to an abstract data type kcondvar_t. >> >> mp A pointer to a mutual exclusion lock (kmutex_t), >> initialized by mutex_init(9F) and held by the >> caller. >> >> name Descriptive string. This is obsolete and should >> be NULL. (Non-NULL strings are legal, but they're >> a waste of kernel memory.) >> >> SunOS 5.11 Last change: 02 Aug 2009 1 >> >> Kernel Functions for Drivers condvar(9F) >> >> type The constant CV_DRIVER. >> >> arg A type-specific argument, drivers should pass arg >> as NULL. >> >> timeout A time, in absolute ticks since boot, when >> cv_timedwait() or cv_timedwait_sig() should >> return. >> >> | delta A time, in relative ticks, when cv_reltimedwait() >> | or cv_reltimedwait_sig() should return. >> | >> | resolution A flag that specifies how accurately the relative >> | time interval should be. Possible values are >> | TR_NANOSEC, TR_MICROSEC, TR_MILLISEC, TR_SEC or >> | TR_CLOCK_TICK, the former indicating that the interval >> | should be aligned to system clock ticks. This >> | information allows the system to anticipate or >> | deffer the timeout expiration in order to batch process >> | similarly expiring events. Allowing the system to >> | stay idle for longer periods of time and enhance >> | its power efficiency. >> >> >> DESCRIPTION >> Condition variables are a standard form of thread synchroni- >> zation. They are designed to be used with mutual exclusion >> locks (mutexes). The associated mutex is used to ensure that >> a condition can be checked atomically and that the thread >> can block on the associated condition variable without miss- >> ing either a change to the condition or a signal that the >> condition has changed. Condition variables must be initial- >> ized by calling cv_init(), and must be deallocated by cal- >> ling cv_destroy(). >> >> The usual use of condition variables is to check a condition >> (for example, device state, data structure reference count, >> etc.) while holding a mutex which keeps other threads from >> changing the condition. If the condition is such that the >> thread should block, cv_wait() is called with a related con- >> dition variable and the mutex. At some later point in time, >> another thread would acquire the mutex, set the condition >> such that the previous thread can be unblocked, unblock the >> previous thread with cv_signal() or cv_broadcast(), and then >> release the mutex. >> >> cv_wait() suspends the calling thread and exits the mutex >> atomically so that another thread which holds the mutex can- >> not signal on the condition variable until the blocking >> thread is blocked. Before returning, the mutex is reac- >> quired. >> >> cv_signal() signals the condition and wakes one blocked >> thread. All blocked threads can be unblocked by calling >> cv_broadcast(). cv_signal() and cv_broadcast() can be called >> by a thread even if it does not hold the mutex passed into >> cv_wait(), though holding the mutex is necessary to ensure >> predictable scheduling. >> >> SunOS 5.11 Last change: 02 Aug 2009 2 >> >> Kernel Functions for Drivers condvar(9F) >> >> The function cv_wait_sig() is similar to cv_wait() but >> returns 0 if a signal (for example, by kill(2)) is sent to >> the thread. In any case, the mutex is reacquired before >> returning. >> >> The function cv_timedwait() is similar to cv_wait(), except >> that it returns -1 without the condition being signaled >> after the timeout time has been reached. >> >> The function cv_timedwait_sig() is similar to cv_timedwait() >> and cv_wait_sig(), except that it returns -1 without the >> condition being signaled after the timeout time has been >> reached, or 0 if a signal (for example, by kill(2)) is sent >> to the thread. >> >> For both cv_timedwait() and cv_timedwait_sig(), time is in >> absolute clock ticks since the last system reboot. The >> current time may be found by calling ddi_get_lbolt(9F). >> >> | The cv_reltimedwait() function is similar to cv_timedwait(), >> | except that it takes a relative time value as argument and >> | it also takes an additional argument to specify the accuracy >> | of such interval. cv_reltimedwait_sig() is analogous to >> | cv_timedwait_sig(), but takes the same arguments as >> | cv_reltimedwait(). >> >> RETURN VALUES >> 0 For cv_wait_sig(), cv_timedwait_sig() and >> cv_reltimedwait_sig() >> indicates >> that the condition was not necessarily signaled and >> the function returned because a signal (as in >> kill(2)) was pending. >> >> | -1 For cv_timedwait(), cv_timedwait_sig(), >> | cv_reltimedwait() and cv_reltimedwait_sig() indicates >> that the condition was not necessarily signaled and >> the function returned because the timeout time was >> reached. >> >> | >0 For cv_wait_sig(), cv_timedwait(), cv_timedwait_sig(), >> | cv_reltimedwait() or cv_reltimedwait_sig() >> | indicates that the condition was >> met and the function returned due to a call to >> cv_signal() or cv_broadcast(), or due to a prema- >> ture wakeup (see NOTES). >> >> CONTEXT >> These functions can be called from user, kernel or interrupt >> context. In most cases, however, cv_wait(), cv_timedwait(), >> | cv_wait_sig(), cv_timedwait_sig(), cv_reltimedwait() and >> | cv_reltimedwait_sig() >> should not be called >> from interrupt context, and cannot be called from a high- >> level interrupt context. >> >> If cv_wait(), cv_timedwait(), cv_wait_sig(), >> | cv_timedwait_sig(), cv_reltimedwait() or cv_reltimedwait_sig() >> | are used from interrupt context, lower- >> >> SunOS 5.11 Last change: 02 Aug 2009 3 >> >> Kernel Functions for Drivers condvar(9F) >> >> priority interrupts will not be serviced during the wait. >> This means that if the thread that will eventually perform >> the wakeup becomes blocked on anything that requires the >> lower-priority interrupt, the system will hang. >> >> For example, the thread that will perform the wakeup may >> need to first allocate memory. This memory allocation may >> require waiting for paging I/O to complete, which may >> require a lower-priority disk or network interrupt to be >> serviced. In general, situations like this are hard to >> predict, so it is advisable to avoid waiting on condition >> variables or semaphores in an interrupt context. >> >> EXAMPLES >> Example 1 Waiting for a Flag Value in a Driver's Unit >> >> Here the condition being waited for is a flag value in a >> driver's unit structure. The condition variable is also in >> the unit structure, and the flag word is protected by a >> mutex in the unit structure. >> >> mutex_enter(&un->un_lock); >> while (un->un_flag & UNIT_BUSY) >> cv_wait(&un->un_cv, &un->un_lock); >> un->un_flag |= UNIT_BUSY; >> mutex_exit(&un->un_lock); >> >> Example 2 Unblocking Threads Blocked by the Code in Example >> 1 >> >> At some later point in time, another thread would execute >> the following to unblock any threads blocked by the above >> code. >> >> mutex_enter(&un->un_lock); >> un->un_flag &= ~UNIT_BUSY; >> cv_broadcast(&un->un_cv); >> mutex_exit(&un->un_lock); >> >> NOTES >> | It is possible for cv_wait(), cv_wait_sig(), cv_timedwait(), >> | cv_timedwait_sig(), cv_reltimedwait() and cv_reltimedwait_sig() >> | to return prematurely, that is, not >> due to a call to cv_signal() or cv_broadcast(). This occurs >> most commonly in the case of cv_wait_sig(), >> >> SunOS 5.11 Last change: 02 Aug 2009 4 >> >> Kernel Functions for Drivers condvar(9F) >> >> | cv_timedwait_sig() and cv_reltimedwait_sig() when the thread >> | is stopped and restarted >> by job control signals or by a debugger, but can happen in >> other cases as well, even for cv_wait(). Code that calls >> these functions must always recheck the reason for blocking >> and call again if the reason for blocking is still true. >> >> | If your driver needs to wait on behalf of processes that >> | have real-time constraints, use cv_timedwait() or >> cv_reltimedwait() >> | rather than >> delay(9F). The delay() function calls timeout(9F), which can >> be subject to priority inversions. >> >> Not all threads can receive signals from user level >> processes. In cases where such reception is impossible (such >> as during execution of close(9E) due to exit(2)), >> cv_wait_sig() behaves as cv_wait(), cv_timedwait_sig() >> | behaves as cv_timedwait() and cv_reltimedwait_sig() behaves as >> | cv_reltimedwait(). >> To avoid unkillable processes, >> users of these functions may need to protect against waiting >> indefinitely for events that might not occur. The >> ddi_can_receive_sig(9F) function is provided to detect when >> signal reception is possible. >> >> SEE ALSO >> kill(2), ddi_can_receive_sig(9F), ddi_get_lbolt(9F), >> | ddi_get_lbolt64(9F), mutex(9F), mutex_init(9F) >> >> Writing Device Drivers >> >> SunOS 5.11 Last change: 02 Aug 2009 5 >> > From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Tue Sep 1 15:00:11 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n81M0AjI024524 for ; Tue, 1 Sep 2009 15:00:11 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n81M060w003847 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 1 Sep 2009 15:00:10 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPB0030HBS9NU00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Sep 2009 15:00:09 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPB00DXGBS8CZ60@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Sep 2009 15:00:08 -0700 (PDT) Received: from relay43i.sun.com ([192.5.209.74]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n81LqECv011149 for ; Tue, 01 Sep 2009 22:00:08 +0000 (GMT) Received: from mmp41es.mmp.us.syntegra.com ([160.41.221.10] [160.41.221.10]) by relay43i.sun.com with ESMTP id BT-MMP-148839 for PSARC-ext@sun.com; Tue, 01 Sep 2009 22:00:07 +0000 (Z) Received: from relay45i.sun.com (relay45i.sun.com [192.5.209.94]) by mmp41es.mmp.us.syntegra.com with ESMTP id BT-MMP-7217365 for PSARC-ext@sun.com; Tue, 01 Sep 2009 22:00:04 +0000 (Z) Received: from relay03-haj2.antispameurope.com ([83.246.65.53] [83.246.65.53]) by relay4i.sun.com with ESMTP id BT-MMP-464516 for PSARC-ext@sun.com; Tue, 01 Sep 2009 22:00:05 +0000 (Z) Received: by relay03-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id C2D7063C0BE; Wed, 02 Sep 2009 00:00:01 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay03-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 47AAA63C093; Tue, 01 Sep 2009 23:59:59 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id n81LxwQV007326; Tue, 01 Sep 2009 23:59:58 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 01 Sep 2009 23:59:58 +0200 Date: Tue, 01 Sep 2009 23:59:03 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009] In-reply-to: <4A9D90A5.8030905@sun.com> Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com To: Rafael.Vanoni@sun.com, PSARC-ext@sun.com, jerry.gilliam@sun.com Cc: Steve.Sistare@sun.com, Madhavan.Venkataraman@sun.com, jerry.gilliam@sun.com, Eric.Saxe@sun.com Message-id: <4a9d9927./ZRbLvLmxk+UnZdT%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 2.680sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4A9D90A5.8030905@sun.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 01 Sep 2009 21:59:58.0385 (UTC) FILETIME=[8BF30210:01CA2B4F] Status: RO Content-Length: 1127 Jerry Gilliam wrote: > 2. Project Summary > 2.1. Project Description: > The tickless project aims at implementing the services provided by the > clock cyclic in an event driven fashion. The first sub-project is the > decoupling of the lbolt and lbolt64 variables from clock(). These two > variables are incremented at each firing of the clock cyclic and provide > a time reference to the system. They are being replaced by two routines > that are backed by gethrtime(), the existing ddi_get_lbolt() and > the new ddi_get_lbolt64(), introduced as a migration path for existing > non-DDI compliant consumers. If this results in being able to sleep with less than 10 ms granularity without setting a high-res tick, you get many + from me! Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Tue Sep 1 15:00:12 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n81M0BWN024523 for ; Tue, 1 Sep 2009 15:00:11 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n81LxtY0004845 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Sep 2009 06:00:10 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPB00311BS7NR00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Sep 2009 15:00:07 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPB00DXABS6CZ60@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Sep 2009 15:00:07 -0700 (PDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n81LpokC014855 for ; Tue, 01 Sep 2009 22:00:06 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay15i.sun.com with ESMTP id BT-MMP-735717 for PSARC-ext@sun.com; Tue, 01 Sep 2009 22:00:06 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-11242726 for PSARC-ext@sun.com; Tue, 01 Sep 2009 22:00:06 +0000 (Z) Received: from relay03-haj2.antispameurope.com ([83.246.65.53] [83.246.65.53]) by relay1i.sun.com with ESMTP id BT-MMP-22194680 for PSARC-ext@sun.com; Tue, 01 Sep 2009 22:00:05 +0000 (Z) Received: by relay03-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id EF33763C0C7; Wed, 02 Sep 2009 00:00:04 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay03-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 47AAA63C093; Tue, 01 Sep 2009 23:59:59 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id n81LxwQV007326; Tue, 01 Sep 2009 23:59:58 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 01 Sep 2009 23:59:58 +0200 Date: Tue, 01 Sep 2009 23:59:03 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009] In-reply-to: <4A9D90A5.8030905@sun.com> Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com To: Rafael.Vanoni@sun.com, PSARC-ext@sun.com, jerry.gilliam@sun.com Cc: Steve.Sistare@sun.com, Madhavan.Venkataraman@sun.com, jerry.gilliam@sun.com, Eric.Saxe@sun.com Message-id: <4a9d9927./ZRbLvLmxk+UnZdT%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== References: <4A9D90A5.8030905@sun.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 01 Sep 2009 21:59:58.0385 (UTC) FILETIME=[8BF30210:01CA2B4F] Status: RO Content-Length: 1127 Jerry Gilliam wrote: > 2. Project Summary > 2.1. Project Description: > The tickless project aims at implementing the services provided by the > clock cyclic in an event driven fashion. The first sub-project is the > decoupling of the lbolt and lbolt64 variables from clock(). These two > variables are incremented at each firing of the clock cyclic and provide > a time reference to the system. They are being replaced by two routines > that are backed by gethrtime(), the existing ddi_get_lbolt() and > the new ddi_get_lbolt64(), introduced as a migration path for existing > non-DDI compliant consumers. If this results in being able to sleep with less than 10 ms granularity without setting a high-res tick, you get many + from me! Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From gdamore@sun.com Tue Sep 1 15:25:34 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n81MPXmh024866 for ; Tue, 1 Sep 2009 15:25:33 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n81MPXEK028738 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 1 Sep 2009 15:25:33 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPB00B01CYK9X00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Sep 2009 16:25:32 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPB005SUCYJC440@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Sep 2009 16:25:31 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n81MPVQT024596 for ; Tue, 01 Sep 2009 15:25:31 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPB00J00CBGQ800@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Sep 2009 15:25:31 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPB0067XCYHPEE0@fe-sfbay-10.sun.com>; Tue, 01 Sep 2009 15:25:30 -0700 (PDT) Date: Tue, 01 Sep 2009 15:25:29 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009] In-reply-to: <4A9D9657.9010104@sun.com> Sender: Garrett.Damore@sun.com To: Rafael Vanoni Cc: Jerry Gilliam , PSARC-ext@sun.com, Eric Saxe , Madhavan.Venkataraman@sun.com, Steven Sistare Message-id: <4A9D9F59.50600@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A9D90A5.8030905@sun.com> <4A9D94BD.8040000@sun.com> <4A9D9657.9010104@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 26404 Rafael Vanoni wrote: > Hi Garret > > Garrett D'Amore wrote: >> I'm inclined to give this a +1, but I'm also concerned that the >> changes here, while *good*, may exceed the scope of a fast track. >> I'm close to derailing, only to ensure that the case is properly >> reviewed. This is not something that we should have slip in under >> the radar, even if I think the changes are all *good*. :-) >> >> If any other member is in agreement with me, let me know, and I'll >> derail it. I'm happy to own the case and the opinion duties. :-) If >> however, everyone else feels that this should be left as a fast >> track, then I'll leave it alone. I certainly don't have any >> particular problem with the case as specified, beyond the minor >> issues pointed out below. >> >> Other considerations: >> >> 1) I don't see any changes made to cv_wait and cv_timedwait. Does it >> make sense to obsolete them at the same time that we're introducing >> cv_reltimedwait()? > > There are still many consumers of cv_timedwait who need to pass in an > absolute time. cv_wait serves a similar purpose but without the timed > component, so it's functionality doesn't overlap with cv_reltimedwait(). Really? In device drivers? Because darn near every time I've used cv_timedwait (and I've used it a *lot* over my career), what I really wanted was a relative time (usually for a timeout.) I can't think of any reason in normal kernel code why you'd want an *absolute* time. (Apart from the kernel proper, where I can see absolute times being useful for wall clock kinds of things.) > >> 2) for enum time_res, it might be convenient to use shorter names, >> using SI abbreviations. I'd suggest: >> >> enum time_res { >> TR_NSEC, >> TR_USEC, >> TR_MSEC, >> TR_SEC, >> TR_TICK, >> TR_COUNT >> }; >> >> (Btw, what is the difference between TR_COUNT and TR_CLOCK_TICK?) > > TR_CLOCK_TICK represents the duration of a clock tick in nanoseconds > (nsec_per_tick). TR_COUNT is simply the number of elements in the > enumeration. Ah, so TR_COUNT is not an exported value then. -- Garrett > > Thanks, > Rafael > >> - Garrett >> >> Jerry Gilliam wrote: >>> >>> I am sponsoring the following fast-track on behalf of Rafael Vanoni, >>> with a time-out of 09/09/2009. The project desires >>> minor/major binding, plus micro/patch binding for one >>> interface, as specified. >>> >>> ------------------------------------- >>> >>> Template Version: @(#)onepager.txt 1.35 07/11/07 SMI >>> Copyright 2007 Sun Microsystems >>> >>> 1. Introduction >>> 1.1. Project/Component Working Name: >>> Tickless Kernel Architecture / lbolt decoupling >>> >>> 1.2. Name of Document Author/Supplier: >>> Rafael Vanoni Polanczyk (rafael.vanoni@sun.com) >>> >>> 1.3. Date of This Document: >>> 08/04/09 >>> >>> 1.3.1. Date this project was conceived: >>> 07/01/09 >>> >>> 1.4. Name of Major Document Customer(s)/Consumer(s): >>> 1.4.1. The PAC or CPT you expect to review your project: >>> Solaris PAC >>> 1.4.2. The ARC(s) you expect to review your project: >>> 1.4.3. The Director/VP who is "Sponsoring" this project: >>> Greg.Lavender@Sun.COM >>> 1.4.4. The name of your business unit: >>> Systems >>> >>> 1.5. Email Aliases: >>> 1.5.1. Responsible Manager: darrin.johnson@sun.com >>> 1.5.2. Responsible Engineer: rafael.vanoni@sun.com >>> 1.5.3. Marketing Manger: mike.mulkey@sun.com >>> 1.5.4. Interest List: tickless-dev@opensolaris.org >>> >>> >>> 2. Project Summary >>> 2.1. Project Description: >>> The tickless project aims at implementing the services >>> provided by the >>> clock cyclic in an event driven fashion. The first >>> sub-project is the >>> decoupling of the lbolt and lbolt64 variables from clock(). >>> These two >>> variables are incremented at each firing of the clock cyclic >>> and provide >>> a time reference to the system. They are being replaced by >>> two routines >>> that are backed by gethrtime(), the existing ddi_get_lbolt() and >>> the new ddi_get_lbolt64(), introduced as a migration path for >>> existing >>> non-DDI compliant consumers. >>> >>> This project also presents a solution to minimize the usage >>> of the DDI >>> lbolt routines through new interfaces, and a method to >>> prevent any >>> performance impact of migrating inexpensive references to >>> variables, to >>> calling of routines. These are described in detail on section >>> 4.1. >>> >>> >>> 4. Technical Description: >>> 4.1. Details: >>> lbolt and lbolt64 variables will be replaced by two routines, >>> ddi_get_lbolt() and ddi_get_lbolt64(), which are backed by a >>> hardware >>> counter to provide the same service in en event driven way. >>> >>> One of the major consumers of the lbolt service are the >>> cv_timedwait() >>> and cv_timedwait_sig() routines, which require lbolt to form >>> one of its >>> arguments (an absolute value of time) and once again >>> internally to >>> decompose it into a relative time. This project is >>> introducing two new >>> routines, cv_reltimedwait() and cv_reltimedwait_sig() which >>> will perform >>> the same service of the previously mentioned routines but simply >>> receiving a relative time, and not requiring lbolt at all. >>> These new >>> routines will also have a new argument of type time_res_t to >>> inform >>> the underlying timeout system as to how accurately the given >>> timeout >>> must expire. This will allow the kernel to anticipate or >>> defer such >>> timeouts when possible, allowing the system to stay idle for >>> longer >>> periods of time. >>> >>> Some consumers of the lbolt and lbolt64 variables may have >>> inexplicit >>> dependencies on the cheapness of reading a memory position >>> that will be >>> exposed when migrated to a gethrtime() backed routine. In >>> such cases >>> migrating references to lbolt and lbolt64 to ddi_get_lbolt() and >>> ddi_get_lbolt64() will have a negative performance impact. To >>> address >>> this case, our project will perform the lbolt service in >>> an hybrid way, >>> switching from event to cyclic driven when the DDI lbolt >>> routines are >>> being heavily used. This cyclic mode will reprogram a timer >>> that will >>> expire at each clock tick and increment an internal (lbolt >>> like) >>> variable and return its value to the consumer. This cyclic >>> will only >>> be activated during periods of heavy load, and will switch >>> itself off >>> when the activity subsides. >>> >>> The decision to remove the lbolt and lbolt64 variables was made >>> during >>> design review, and a consensus was reached on the basis that, since >>> we're reaching the end of a major release, this is the right >>> moment to >>> obsolete these. The side effects and cost of maintaining such >>> symbols >>> outweigh the benefits. However, this decision can be >>> re-evaluated in >>> case the negative impact on 3rd party modules during the >>> development >>> release is greater than expected. We're working with ISV and RPE to >>> minimize the impact pro-actively. >>> >>> 4.2. Bug/RFE Number(s): >>> 6860030 tickless clock requires a clock() decoupled lbolt / >>> lbolt64 >>> >>> 4.5. Interfaces: >>> This project is adding the following interfaces to the DDI: >>> >>> int64_t ddi_get_lbolt64(void); >>> >>> clock_t cv_reltimedwait(kcondvar_t *cvp, kmutex_t *mp, >>> clock_t delta, >>> time_res_t res); >>> >>> clock_t cv_reltimedwait_sig(kcondvar_t *cvp, kmutex_t *mp, >>> clock_t >>> delta, time_res_t res); >>> >>> With time_res_t defined as >>> >>> enum time_res { >>> TR_NANOSEC, >>> TR_MICROSEC, >>> TR_MILLISEC, >>> TR_SEC, >>> TR_CLOCK_TICK, >>> TR_COUNT >>> }; >>> >>> typedef enum time_res time_res_t; >>> >>> In addition to that, the lbolt and lbolt64 variables (which are >>> *private* symbols known to be used by non-DDI compliant >>> modules) are >>> being removed. 3rd party modules that are not brought up to >>> speed will >>> fail to load. >>> >>> In summary: >>> >>> Interface Commitment Comments >>> >>> ----------------------------------------------------------------------- >>> ddi_get_lbolt64() Public/DDI return lbolt64 >>> cv_reltimedwait(9F) Public/DDI cv_timedwait(9f), relative time >>> cv_reltimedwait_sig(9F) Public/DDI cv_timedwait_sig(9F), >>> relative time >>> lbolt Obsolete commonly referenced kernel symbol >>> lbolt64 Obsolete commonly referenced kernel symbol >>> >>> We also plan on back porting the ddi_get_lbolt64() interface to >>> Solaris >>> 10 Update 9 to extend the migration path for S10 users who would >>> like >>> to update their modules before moving to Solaris Nevada or the next >>> version of Solaris. These users already have ddi_get_lbolt() but >>> currently lack the 64 bits version of it. Such back port will have >>> patch release binding. >>> >>> >>> 4.6. Doc Impact: >>> 6868417 updates for tickless kernel/lbolt decoupling (6860030) >>> >>> Updates to the 'Writing Device Drivers' document are >>> necessary, the >>> project team is in contact with the documentation group to >>> address >>> these. >>> >>> >>> 5. Reference Documents: >>> This project is being developed through OpenSolaris, our project >>> pages >>> and alias contain all the necessary information: >>> http://opensolaris.org/os/project/tickless/ >>> http://opensolaris.org/os/project/tickless/tasks/lbolt/ >>> tickless-dev@opensolaris.org >>> >>> >>> 6. Resources and Schedule: >>> 6.5. ARC review type: Fast track >>> 6.6. ARC Exposure: open >>> >>> >>> >>> >>> >>> Updates to existing man pages: >>> ------------------------------ >>> >>> drv_getparm.9f >>> >>> PARAMETERS >>> ... >>> >>> LBOLT Read the value of lbolt. lbolt is a clock_t that | >>> represents the number of clock ticks since system | >>> boot. No special treatment is applied when | >>> this value overflows the maximum value of the >>> signed integral type clock_t. When this occurs, >>> its value will be negative, and its magnitude will >>> be decreasing until it again passes zero. It can >>> ... >>> >>> >>> >>> >>> drv_hztousec.9f >>> >>> DESCRIPTION >>> The drv_hztousec() function converts into microseconds the >>> time expressed by hertz, which is in system clock ticks. >>> >>> The length of time the system has been up since boot can be | >>> retrieved by calling ddi_get_lbolt(9F), which will return a | >>> value of type clock_t containing the number of clock ticks >>> since boot. Drivers often use this value before and after an >>> I/O request to measure the amount of time it took the device to >>> process the request. The drv_hztousec() function can be used >>> by the driver to convert the reading from clock ticks to a >>> known unit of time. >>> >>> >>> >>> >>> Intro.9f >>> >>> Kernel Functions for Drivers Intro(9F) >>> >>> ddi_get_instance Solaris DDI >>> ddi_get_kt_did Solaris DDI >>> ddi_get_lbolt Solaris DDI >>> ddi_get_lbolt64 Solaris DDI + >>> ddi_get_name Solaris DDI >>> ... >>> >>> >>> >>> >>> Updated ddi_get_lbolt.9f: >>> ------------------------- >>> >>> Kernel Functions for Drivers ddi_get_lbolt(9F) >>> >>> NAME >>> ddi_get_lbolt - returns the number of clock ticks since boot | >>> >>> SYNOPSIS >>> #include >>> #include >>> #include >>> >>> clock_t ddi_get_lbolt(void); >>> >>> INTERFACE LEVEL >>> Solaris DDI specific (Solaris DDI). >>> >>> DESCRIPTION >>> ddi_get_lbolt() returns a value that represents the >>> number | >>> of clock ticks since the system booted. This value is | >>> used as a counter or timer inside the system kernel. >>> The tick frequency can be determined by using drv_usectohz(9F) >>> which converts microseconds into clock ticks. >>> >>> >>> RETURN VALUES >>> ddi_get_lbolt() returns the number of clock ticks since boot | >>> in clock_t type. >>> >>> CONTEXT >>> This routine can be called from any context. >>> >>> SEE ALSO >>> ddi_get_lbolt64(9F), ddi_get_time(9F), drv_getparm(9F), >>> drv_usectohz(9F) >>> >>> >>> >>> >>> New man page for ddi_get_lbolt64(): >>> ----------------------------------- >>> >>> Kernel Functions for Drivers ddi_get_lbolt64(9F) >>> >>> NAME >>> ddi_get_lbolt64 - returns the number of clock ticks since boot >>> in int64_t type >>> >>> SYNOPSIS >>> #include >>> #include >>> #include >>> >>> int64_t ddi_get_lbolt64(void); >>> >>> INTERFACE LEVEL >>> Solaris DDI specific (Solaris DDI). >>> >>> DESCRIPTION >>> ddi_get_lbolt64() returns a value that represents the number >>> of clock ticks since the system booted. This value is >>> used as a counter or timer inside the system kernel. It is >>> essentially the same value returned by ddi_get_lbolt(9F), but in a >>> longer data type that will not wrap for 2.9 billion years. >>> >>> RETURN VALUES >>> ddi_get_lbolt64() returns the number of clock ticks since boot >>> in int64_t type. >>> >>> CONTEXT >>> This routine can be called from any context. >>> >>> SEE ALSO >>> ddi_get_lbolt(9F), ddi_get_time(9F) >>> >>> Writing Device Drivers >>> >>> STREAMS Programming Guide >>> >>> SunOS 5.11 Last change: 29 Jul 2009 1 >>> >>> >>> Updates to condvar(9f): >>> ---------------------- >>> >>> Kernel Functions for Drivers condvar(9F) >>> >>> NAME >>> condvar, cv_init, cv_destroy, cv_wait, cv_signal, >>> cv_broadcast, cv_wait_sig, cv_timedwait, cv_timedwait_sig, >>> cv_reltimedwait, cv_reltimedwait_sig - condition variable >>> routines >>> >>> SYNOPSIS >>> #include >>> >>> void cv_init(kcondvar_t *cvp, char *name, kcv_type_t type, void >>> *arg); >>> >>> void cv_destroy(kcondvar_t *cvp); >>> >>> void cv_wait(kcondvar_t *cvp, kmutex_t *mp); >>> >>> void cv_signal(kcondvar_t *cvp); >>> >>> void cv_broadcast(kcondvar_t *cvp); >>> >>> int cv_wait_sig(kcondvar_t *cvp, kmutex_t *mp); >>> >>> clock_t cv_timedwait(kcondvar_t *cvp, kmutex_t *mp, clock_t >>> timeout); >>> >>> clock_t cv_timedwait_sig(kcondvar_t *cvp, kmutex_t *mp, clock_t >>> timeout); >>> >>> | clock_t cv_reltimedwait(kcondvar_t *cvp, kmutex_t *mp, clock_t >>> delta, >>> | time_res_t resolution); >>> >>> | clock_t cv_reltimedwait_sig(kcondvar_t *cvp, kmutex_t *mp, >>> clock_t delta, >>> | time_res_t resolution); >>> >>> INTERFACE LEVEL >>> Solaris DDI specific (Solaris DDI). >>> >>> PARAMETERS >>> cvp A pointer to an abstract data type kcondvar_t. >>> >>> mp A pointer to a mutual exclusion lock (kmutex_t), >>> initialized by mutex_init(9F) and held by the >>> caller. >>> >>> name Descriptive string. This is obsolete and should >>> be NULL. (Non-NULL strings are legal, but they're >>> a waste of kernel memory.) >>> >>> SunOS 5.11 Last change: 02 Aug 2009 1 >>> >>> Kernel Functions for Drivers condvar(9F) >>> >>> type The constant CV_DRIVER. >>> >>> arg A type-specific argument, drivers should pass arg >>> as NULL. >>> >>> timeout A time, in absolute ticks since boot, when >>> cv_timedwait() or cv_timedwait_sig() should >>> return. >>> >>> | delta A time, in relative ticks, when cv_reltimedwait() >>> | or cv_reltimedwait_sig() should return. >>> | >>> | resolution A flag that specifies how accurately the relative >>> | time interval should be. Possible values are >>> | TR_NANOSEC, TR_MICROSEC, TR_MILLISEC, TR_SEC or >>> | TR_CLOCK_TICK, the former indicating that the interval >>> | should be aligned to system clock ticks. This >>> | information allows the system to anticipate or >>> | deffer the timeout expiration in order to batch process >>> | similarly expiring events. Allowing the system to >>> | stay idle for longer periods of time and enhance >>> | its power efficiency. >>> >>> >>> DESCRIPTION >>> Condition variables are a standard form of thread synchroni- >>> zation. They are designed to be used with mutual exclusion >>> locks (mutexes). The associated mutex is used to ensure that >>> a condition can be checked atomically and that the thread >>> can block on the associated condition variable without miss- >>> ing either a change to the condition or a signal that the >>> condition has changed. Condition variables must be initial- >>> ized by calling cv_init(), and must be deallocated by cal- >>> ling cv_destroy(). >>> >>> The usual use of condition variables is to check a condition >>> (for example, device state, data structure reference count, >>> etc.) while holding a mutex which keeps other threads from >>> changing the condition. If the condition is such that the >>> thread should block, cv_wait() is called with a related con- >>> dition variable and the mutex. At some later point in time, >>> another thread would acquire the mutex, set the condition >>> such that the previous thread can be unblocked, unblock the >>> previous thread with cv_signal() or cv_broadcast(), and then >>> release the mutex. >>> >>> cv_wait() suspends the calling thread and exits the mutex >>> atomically so that another thread which holds the mutex can- >>> not signal on the condition variable until the blocking >>> thread is blocked. Before returning, the mutex is reac- >>> quired. >>> >>> cv_signal() signals the condition and wakes one blocked >>> thread. All blocked threads can be unblocked by calling >>> cv_broadcast(). cv_signal() and cv_broadcast() can be called >>> by a thread even if it does not hold the mutex passed into >>> cv_wait(), though holding the mutex is necessary to ensure >>> predictable scheduling. >>> >>> SunOS 5.11 Last change: 02 Aug 2009 2 >>> >>> Kernel Functions for Drivers condvar(9F) >>> >>> The function cv_wait_sig() is similar to cv_wait() but >>> returns 0 if a signal (for example, by kill(2)) is sent to >>> the thread. In any case, the mutex is reacquired before >>> returning. >>> >>> The function cv_timedwait() is similar to cv_wait(), except >>> that it returns -1 without the condition being signaled >>> after the timeout time has been reached. >>> >>> The function cv_timedwait_sig() is similar to cv_timedwait() >>> and cv_wait_sig(), except that it returns -1 without the >>> condition being signaled after the timeout time has been >>> reached, or 0 if a signal (for example, by kill(2)) is sent >>> to the thread. >>> >>> For both cv_timedwait() and cv_timedwait_sig(), time is in >>> absolute clock ticks since the last system reboot. The >>> current time may be found by calling ddi_get_lbolt(9F). >>> >>> | The cv_reltimedwait() function is similar to cv_timedwait(), >>> | except that it takes a relative time value as argument and >>> | it also takes an additional argument to specify the accuracy >>> | of such interval. cv_reltimedwait_sig() is analogous to >>> | cv_timedwait_sig(), but takes the same arguments as >>> | cv_reltimedwait(). >>> >>> RETURN VALUES >>> 0 For cv_wait_sig(), cv_timedwait_sig() and >>> cv_reltimedwait_sig() >>> indicates >>> that the condition was not necessarily signaled and >>> the function returned because a signal (as in >>> kill(2)) was pending. >>> >>> | -1 For cv_timedwait(), cv_timedwait_sig(), >>> | cv_reltimedwait() and cv_reltimedwait_sig() indicates >>> that the condition was not necessarily signaled and >>> the function returned because the timeout time was >>> reached. >>> >>> | >0 For cv_wait_sig(), cv_timedwait(), cv_timedwait_sig(), >>> | cv_reltimedwait() or cv_reltimedwait_sig() >>> | indicates that the condition was >>> met and the function returned due to a call to >>> cv_signal() or cv_broadcast(), or due to a prema- >>> ture wakeup (see NOTES). >>> >>> CONTEXT >>> These functions can be called from user, kernel or interrupt >>> context. In most cases, however, cv_wait(), cv_timedwait(), >>> | cv_wait_sig(), cv_timedwait_sig(), cv_reltimedwait() and >>> | cv_reltimedwait_sig() >>> should not be called >>> from interrupt context, and cannot be called from a high- >>> level interrupt context. >>> >>> If cv_wait(), cv_timedwait(), cv_wait_sig(), >>> | cv_timedwait_sig(), cv_reltimedwait() or cv_reltimedwait_sig() >>> | are used from interrupt context, lower- >>> >>> SunOS 5.11 Last change: 02 Aug 2009 3 >>> >>> Kernel Functions for Drivers condvar(9F) >>> >>> priority interrupts will not be serviced during the wait. >>> This means that if the thread that will eventually perform >>> the wakeup becomes blocked on anything that requires the >>> lower-priority interrupt, the system will hang. >>> >>> For example, the thread that will perform the wakeup may >>> need to first allocate memory. This memory allocation may >>> require waiting for paging I/O to complete, which may >>> require a lower-priority disk or network interrupt to be >>> serviced. In general, situations like this are hard to >>> predict, so it is advisable to avoid waiting on condition >>> variables or semaphores in an interrupt context. >>> >>> EXAMPLES >>> Example 1 Waiting for a Flag Value in a Driver's Unit >>> >>> Here the condition being waited for is a flag value in a >>> driver's unit structure. The condition variable is also in >>> the unit structure, and the flag word is protected by a >>> mutex in the unit structure. >>> >>> mutex_enter(&un->un_lock); >>> while (un->un_flag & UNIT_BUSY) >>> cv_wait(&un->un_cv, &un->un_lock); >>> un->un_flag |= UNIT_BUSY; >>> mutex_exit(&un->un_lock); >>> >>> Example 2 Unblocking Threads Blocked by the Code in Example >>> 1 >>> >>> At some later point in time, another thread would execute >>> the following to unblock any threads blocked by the above >>> code. >>> >>> mutex_enter(&un->un_lock); >>> un->un_flag &= ~UNIT_BUSY; >>> cv_broadcast(&un->un_cv); >>> mutex_exit(&un->un_lock); >>> >>> NOTES >>> | It is possible for cv_wait(), cv_wait_sig(), cv_timedwait(), >>> | cv_timedwait_sig(), cv_reltimedwait() and cv_reltimedwait_sig() >>> | to return prematurely, that is, not >>> due to a call to cv_signal() or cv_broadcast(). This occurs >>> most commonly in the case of cv_wait_sig(), >>> >>> SunOS 5.11 Last change: 02 Aug 2009 4 >>> >>> Kernel Functions for Drivers condvar(9F) >>> >>> | cv_timedwait_sig() and cv_reltimedwait_sig() when the thread >>> | is stopped and restarted >>> by job control signals or by a debugger, but can happen in >>> other cases as well, even for cv_wait(). Code that calls >>> these functions must always recheck the reason for blocking >>> and call again if the reason for blocking is still true. >>> >>> | If your driver needs to wait on behalf of processes that >>> | have real-time constraints, use cv_timedwait() or >>> cv_reltimedwait() >>> | rather than >>> delay(9F). The delay() function calls timeout(9F), which can >>> be subject to priority inversions. >>> >>> Not all threads can receive signals from user level >>> processes. In cases where such reception is impossible (such >>> as during execution of close(9E) due to exit(2)), >>> cv_wait_sig() behaves as cv_wait(), cv_timedwait_sig() >>> | behaves as cv_timedwait() and cv_reltimedwait_sig() behaves as >>> | cv_reltimedwait(). >>> To avoid unkillable processes, >>> users of these functions may need to protect against waiting >>> indefinitely for events that might not occur. The >>> ddi_can_receive_sig(9F) function is provided to detect when >>> signal reception is possible. >>> >>> SEE ALSO >>> kill(2), ddi_can_receive_sig(9F), ddi_get_lbolt(9F), >>> | ddi_get_lbolt64(9F), mutex(9F), mutex_init(9F) >>> >>> Writing Device Drivers >>> >>> SunOS 5.11 Last change: 02 Aug 2009 5 >>> >> > From gdamore@sun.com Tue Sep 1 15:31:43 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n81MVgiJ025195 for ; Tue, 1 Sep 2009 15:31:43 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n81MVgVU024918 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 1 Sep 2009 16:31:42 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPB00007D8S4B00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Sep 2009 15:31:40 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPB00KKGD8REB20@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Sep 2009 15:31:39 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n81MVdhX020227 for ; Tue, 01 Sep 2009 15:31:39 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPB00C00D0ZRS00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Sep 2009 15:31:39 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPB00671D8PPEG0@fe-sfbay-10.sun.com>; Tue, 01 Sep 2009 15:31:38 -0700 (PDT) Date: Tue, 01 Sep 2009 15:31:37 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009] In-reply-to: <4a9d9927./ZRbLvLmxk+UnZdT%Joerg.Schilling@fokus.fraunhofer.de> Sender: Garrett.Damore@sun.com To: Joerg Schilling Cc: Rafael.Vanoni@sun.com, PSARC-ext@sun.com, Jerry.Gilliam@sun.com, Steve.Sistare@sun.com, Madhavan.Venkataraman@sun.com, Eric.Saxe@sun.com Message-id: <4A9DA0C9.1020502@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A9D90A5.8030905@sun.com> <4a9d9927./ZRbLvLmxk+UnZdT%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1370 Joerg Schilling wrote: > Jerry Gilliam wrote: > > >> 2. Project Summary >> 2.1. Project Description: >> The tickless project aims at implementing the services provided by the >> clock cyclic in an event driven fashion. The first sub-project is the >> decoupling of the lbolt and lbolt64 variables from clock(). These two >> variables are incremented at each firing of the clock cyclic and provide >> a time reference to the system. They are being replaced by two routines >> that are backed by gethrtime(), the existing ddi_get_lbolt() and >> the new ddi_get_lbolt64(), introduced as a migration path for existing >> non-DDI compliant consumers. >> > > If this results in being able to sleep with less than 10 ms granularity without > setting a high-res tick, you get many + from me! > Actually, I could really use the ability to use a timer based service that had a smaller window than 10 msec. For example, many audio devices have crummy interrupt capabilities... its a lot nicer (smoother audio) if I have a reliable way to get a periodic running at smaller intervals. (5 to 10 msec, but with precision -- the current stuff is simply too coarse.) This would simplify a lot of audio device drivers. And make them more robust as well. :-) - Garrett From Rafael.Vanoni@sun.com Tue Sep 1 15:35:23 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n81MZNqK025375 for ; Tue, 1 Sep 2009 15:35:23 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n81MZHVZ026670 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 1 Sep 2009 16:35:22 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPB0002LDEXCS00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Sep 2009 15:35:21 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPB00KSUDEWEB20@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Sep 2009 15:35:20 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n81MZKPC020621 for ; Tue, 01 Sep 2009 15:35:20 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPB00J00D6SCV00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Sep 2009 15:35:20 -0700 (PDT) Received: from [129.146.229.172] ([unknown] [129.146.229.172]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPB008YTDEVQ7B0@fe-sfbay-09.sun.com>; Tue, 01 Sep 2009 15:35:20 -0700 (PDT) Date: Tue, 01 Sep 2009 15:35:19 -0700 From: Rafael Vanoni Subject: Re: PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009] In-reply-to: <4A9D9F59.50600@sun.com> Sender: Rafael.Vanoni@sun.com To: "Garrett D'Amore" Cc: Jerry Gilliam , PSARC-ext@sun.com, Eric Saxe , Madhavan.Venkataraman@sun.com, Steven Sistare Message-id: <4A9DA1A7.2060308@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A9D90A5.8030905@sun.com> <4A9D94BD.8040000@sun.com> <4A9D9657.9010104@sun.com> <4A9D9F59.50600@sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090804) Status: RO Content-Length: 27248 Garrett D'Amore wrote: > Rafael Vanoni wrote: >> Hi Garret >> >> Garrett D'Amore wrote: >>> I'm inclined to give this a +1, but I'm also concerned that the >>> changes here, while *good*, may exceed the scope of a fast track. >>> I'm close to derailing, only to ensure that the case is properly >>> reviewed. This is not something that we should have slip in under >>> the radar, even if I think the changes are all *good*. :-) >>> >>> If any other member is in agreement with me, let me know, and I'll >>> derail it. I'm happy to own the case and the opinion duties. :-) If >>> however, everyone else feels that this should be left as a fast >>> track, then I'll leave it alone. I certainly don't have any >>> particular problem with the case as specified, beyond the minor >>> issues pointed out below. >>> >>> Other considerations: >>> >>> 1) I don't see any changes made to cv_wait and cv_timedwait. Does it >>> make sense to obsolete them at the same time that we're introducing >>> cv_reltimedwait()? >> >> There are still many consumers of cv_timedwait who need to pass in an >> absolute time. cv_wait serves a similar purpose but without the timed >> component, so it's functionality doesn't overlap with cv_reltimedwait(). > > Really? In device drivers? Because darn near every time I've used > cv_timedwait (and I've used it a *lot* over my career), what I really > wanted was a relative time (usually for a timeout.) I can't think of > any reason in normal kernel code why you'd want an *absolute* time. > (Apart from the kernel proper, where I can see absolute times being > useful for wall clock kinds of things.) Yes, both in kernel and drivers (iwh and iwk2, for instance). I can come up with a list if you're interested. Raf >> >>> 2) for enum time_res, it might be convenient to use shorter names, >>> using SI abbreviations. I'd suggest: >>> >>> enum time_res { >>> TR_NSEC, >>> TR_USEC, >>> TR_MSEC, >>> TR_SEC, >>> TR_TICK, >>> TR_COUNT >>> }; >>> >>> (Btw, what is the difference between TR_COUNT and TR_CLOCK_TICK?) >> >> TR_CLOCK_TICK represents the duration of a clock tick in nanoseconds >> (nsec_per_tick). TR_COUNT is simply the number of elements in the >> enumeration. > > Ah, so TR_COUNT is not an exported value then. > > -- Garrett >> >> Thanks, >> Rafael >> >>> - Garrett >>> >>> Jerry Gilliam wrote: >>>> >>>> I am sponsoring the following fast-track on behalf of Rafael Vanoni, >>>> with a time-out of 09/09/2009. The project desires >>>> minor/major binding, plus micro/patch binding for one >>>> interface, as specified. >>>> >>>> ------------------------------------- >>>> >>>> Template Version: @(#)onepager.txt 1.35 07/11/07 SMI >>>> Copyright 2007 Sun Microsystems >>>> >>>> 1. Introduction >>>> 1.1. Project/Component Working Name: >>>> Tickless Kernel Architecture / lbolt decoupling >>>> >>>> 1.2. Name of Document Author/Supplier: >>>> Rafael Vanoni Polanczyk (rafael.vanoni@sun.com) >>>> >>>> 1.3. Date of This Document: >>>> 08/04/09 >>>> >>>> 1.3.1. Date this project was conceived: >>>> 07/01/09 >>>> >>>> 1.4. Name of Major Document Customer(s)/Consumer(s): >>>> 1.4.1. The PAC or CPT you expect to review your project: >>>> Solaris PAC >>>> 1.4.2. The ARC(s) you expect to review your project: >>>> 1.4.3. The Director/VP who is "Sponsoring" this project: >>>> Greg.Lavender@Sun.COM >>>> 1.4.4. The name of your business unit: >>>> Systems >>>> >>>> 1.5. Email Aliases: >>>> 1.5.1. Responsible Manager: darrin.johnson@sun.com >>>> 1.5.2. Responsible Engineer: rafael.vanoni@sun.com >>>> 1.5.3. Marketing Manger: mike.mulkey@sun.com >>>> 1.5.4. Interest List: tickless-dev@opensolaris.org >>>> >>>> >>>> 2. Project Summary >>>> 2.1. Project Description: >>>> The tickless project aims at implementing the services >>>> provided by the >>>> clock cyclic in an event driven fashion. The first >>>> sub-project is the >>>> decoupling of the lbolt and lbolt64 variables from clock(). >>>> These two >>>> variables are incremented at each firing of the clock cyclic >>>> and provide >>>> a time reference to the system. They are being replaced by >>>> two routines >>>> that are backed by gethrtime(), the existing ddi_get_lbolt() and >>>> the new ddi_get_lbolt64(), introduced as a migration path for >>>> existing >>>> non-DDI compliant consumers. >>>> >>>> This project also presents a solution to minimize the usage >>>> of the DDI >>>> lbolt routines through new interfaces, and a method to >>>> prevent any >>>> performance impact of migrating inexpensive references to >>>> variables, to >>>> calling of routines. These are described in detail on section >>>> 4.1. >>>> >>>> >>>> 4. Technical Description: >>>> 4.1. Details: >>>> lbolt and lbolt64 variables will be replaced by two routines, >>>> ddi_get_lbolt() and ddi_get_lbolt64(), which are backed by a >>>> hardware >>>> counter to provide the same service in en event driven way. >>>> >>>> One of the major consumers of the lbolt service are the >>>> cv_timedwait() >>>> and cv_timedwait_sig() routines, which require lbolt to form >>>> one of its >>>> arguments (an absolute value of time) and once again >>>> internally to >>>> decompose it into a relative time. This project is >>>> introducing two new >>>> routines, cv_reltimedwait() and cv_reltimedwait_sig() which >>>> will perform >>>> the same service of the previously mentioned routines but simply >>>> receiving a relative time, and not requiring lbolt at all. >>>> These new >>>> routines will also have a new argument of type time_res_t to >>>> inform >>>> the underlying timeout system as to how accurately the given >>>> timeout >>>> must expire. This will allow the kernel to anticipate or >>>> defer such >>>> timeouts when possible, allowing the system to stay idle for >>>> longer >>>> periods of time. >>>> >>>> Some consumers of the lbolt and lbolt64 variables may have >>>> inexplicit >>>> dependencies on the cheapness of reading a memory position >>>> that will be >>>> exposed when migrated to a gethrtime() backed routine. In >>>> such cases >>>> migrating references to lbolt and lbolt64 to ddi_get_lbolt() and >>>> ddi_get_lbolt64() will have a negative performance impact. To >>>> address >>>> this case, our project will perform the lbolt service in >>>> an hybrid way, >>>> switching from event to cyclic driven when the DDI lbolt >>>> routines are >>>> being heavily used. This cyclic mode will reprogram a timer >>>> that will >>>> expire at each clock tick and increment an internal (lbolt >>>> like) >>>> variable and return its value to the consumer. This cyclic >>>> will only >>>> be activated during periods of heavy load, and will switch >>>> itself off >>>> when the activity subsides. >>>> >>>> The decision to remove the lbolt and lbolt64 variables was made >>>> during >>>> design review, and a consensus was reached on the basis that, since >>>> we're reaching the end of a major release, this is the right >>>> moment to >>>> obsolete these. The side effects and cost of maintaining such >>>> symbols >>>> outweigh the benefits. However, this decision can be >>>> re-evaluated in >>>> case the negative impact on 3rd party modules during the >>>> development >>>> release is greater than expected. We're working with ISV and RPE to >>>> minimize the impact pro-actively. >>>> >>>> 4.2. Bug/RFE Number(s): >>>> 6860030 tickless clock requires a clock() decoupled lbolt / >>>> lbolt64 >>>> >>>> 4.5. Interfaces: >>>> This project is adding the following interfaces to the DDI: >>>> >>>> int64_t ddi_get_lbolt64(void); >>>> >>>> clock_t cv_reltimedwait(kcondvar_t *cvp, kmutex_t *mp, >>>> clock_t delta, >>>> time_res_t res); >>>> >>>> clock_t cv_reltimedwait_sig(kcondvar_t *cvp, kmutex_t *mp, >>>> clock_t >>>> delta, time_res_t res); >>>> >>>> With time_res_t defined as >>>> >>>> enum time_res { >>>> TR_NANOSEC, >>>> TR_MICROSEC, >>>> TR_MILLISEC, >>>> TR_SEC, >>>> TR_CLOCK_TICK, >>>> TR_COUNT >>>> }; >>>> >>>> typedef enum time_res time_res_t; >>>> >>>> In addition to that, the lbolt and lbolt64 variables (which are >>>> *private* symbols known to be used by non-DDI compliant >>>> modules) are >>>> being removed. 3rd party modules that are not brought up to >>>> speed will >>>> fail to load. >>>> >>>> In summary: >>>> >>>> Interface Commitment Comments >>>> >>>> ----------------------------------------------------------------------- >>>> ddi_get_lbolt64() Public/DDI return lbolt64 >>>> cv_reltimedwait(9F) Public/DDI cv_timedwait(9f), relative time >>>> cv_reltimedwait_sig(9F) Public/DDI cv_timedwait_sig(9F), >>>> relative time >>>> lbolt Obsolete commonly referenced kernel symbol >>>> lbolt64 Obsolete commonly referenced kernel symbol >>>> >>>> We also plan on back porting the ddi_get_lbolt64() interface to >>>> Solaris >>>> 10 Update 9 to extend the migration path for S10 users who would >>>> like >>>> to update their modules before moving to Solaris Nevada or the next >>>> version of Solaris. These users already have ddi_get_lbolt() but >>>> currently lack the 64 bits version of it. Such back port will have >>>> patch release binding. >>>> >>>> >>>> 4.6. Doc Impact: >>>> 6868417 updates for tickless kernel/lbolt decoupling (6860030) >>>> >>>> Updates to the 'Writing Device Drivers' document are >>>> necessary, the >>>> project team is in contact with the documentation group to >>>> address >>>> these. >>>> >>>> >>>> 5. Reference Documents: >>>> This project is being developed through OpenSolaris, our project >>>> pages >>>> and alias contain all the necessary information: >>>> http://opensolaris.org/os/project/tickless/ >>>> http://opensolaris.org/os/project/tickless/tasks/lbolt/ >>>> tickless-dev@opensolaris.org >>>> >>>> >>>> 6. Resources and Schedule: >>>> 6.5. ARC review type: Fast track >>>> 6.6. ARC Exposure: open >>>> >>>> >>>> >>>> >>>> >>>> Updates to existing man pages: >>>> ------------------------------ >>>> >>>> drv_getparm.9f >>>> >>>> PARAMETERS >>>> ... >>>> >>>> LBOLT Read the value of lbolt. lbolt is a clock_t that | >>>> represents the number of clock ticks since system | >>>> boot. No special treatment is applied when | >>>> this value overflows the maximum value of the >>>> signed integral type clock_t. When this occurs, >>>> its value will be negative, and its magnitude will >>>> be decreasing until it again passes zero. It can >>>> ... >>>> >>>> >>>> >>>> >>>> drv_hztousec.9f >>>> >>>> DESCRIPTION >>>> The drv_hztousec() function converts into microseconds the >>>> time expressed by hertz, which is in system clock ticks. >>>> >>>> The length of time the system has been up since boot can be | >>>> retrieved by calling ddi_get_lbolt(9F), which will return a | >>>> value of type clock_t containing the number of clock ticks >>>> since boot. Drivers often use this value before and after an >>>> I/O request to measure the amount of time it took the device to >>>> process the request. The drv_hztousec() function can be used >>>> by the driver to convert the reading from clock ticks to a >>>> known unit of time. >>>> >>>> >>>> >>>> >>>> Intro.9f >>>> >>>> Kernel Functions for Drivers Intro(9F) >>>> >>>> ddi_get_instance Solaris DDI >>>> ddi_get_kt_did Solaris DDI >>>> ddi_get_lbolt Solaris DDI >>>> ddi_get_lbolt64 Solaris DDI + >>>> ddi_get_name Solaris DDI >>>> ... >>>> >>>> >>>> >>>> >>>> Updated ddi_get_lbolt.9f: >>>> ------------------------- >>>> >>>> Kernel Functions for Drivers ddi_get_lbolt(9F) >>>> >>>> NAME >>>> ddi_get_lbolt - returns the number of clock ticks since boot | >>>> >>>> SYNOPSIS >>>> #include >>>> #include >>>> #include >>>> >>>> clock_t ddi_get_lbolt(void); >>>> >>>> INTERFACE LEVEL >>>> Solaris DDI specific (Solaris DDI). >>>> >>>> DESCRIPTION >>>> ddi_get_lbolt() returns a value that represents the >>>> number | >>>> of clock ticks since the system booted. This value is | >>>> used as a counter or timer inside the system kernel. >>>> The tick frequency can be determined by using drv_usectohz(9F) >>>> which converts microseconds into clock ticks. >>>> >>>> >>>> RETURN VALUES >>>> ddi_get_lbolt() returns the number of clock ticks since boot | >>>> in clock_t type. >>>> >>>> CONTEXT >>>> This routine can be called from any context. >>>> >>>> SEE ALSO >>>> ddi_get_lbolt64(9F), ddi_get_time(9F), drv_getparm(9F), >>>> drv_usectohz(9F) >>>> >>>> >>>> >>>> >>>> New man page for ddi_get_lbolt64(): >>>> ----------------------------------- >>>> >>>> Kernel Functions for Drivers ddi_get_lbolt64(9F) >>>> >>>> NAME >>>> ddi_get_lbolt64 - returns the number of clock ticks since boot >>>> in int64_t type >>>> >>>> SYNOPSIS >>>> #include >>>> #include >>>> #include >>>> >>>> int64_t ddi_get_lbolt64(void); >>>> >>>> INTERFACE LEVEL >>>> Solaris DDI specific (Solaris DDI). >>>> >>>> DESCRIPTION >>>> ddi_get_lbolt64() returns a value that represents the number >>>> of clock ticks since the system booted. This value is >>>> used as a counter or timer inside the system kernel. It is >>>> essentially the same value returned by ddi_get_lbolt(9F), but in a >>>> longer data type that will not wrap for 2.9 billion years. >>>> >>>> RETURN VALUES >>>> ddi_get_lbolt64() returns the number of clock ticks since boot >>>> in int64_t type. >>>> >>>> CONTEXT >>>> This routine can be called from any context. >>>> >>>> SEE ALSO >>>> ddi_get_lbolt(9F), ddi_get_time(9F) >>>> >>>> Writing Device Drivers >>>> >>>> STREAMS Programming Guide >>>> >>>> SunOS 5.11 Last change: 29 Jul 2009 1 >>>> >>>> >>>> Updates to condvar(9f): >>>> ---------------------- >>>> >>>> Kernel Functions for Drivers condvar(9F) >>>> >>>> NAME >>>> condvar, cv_init, cv_destroy, cv_wait, cv_signal, >>>> cv_broadcast, cv_wait_sig, cv_timedwait, cv_timedwait_sig, >>>> cv_reltimedwait, cv_reltimedwait_sig - condition variable >>>> routines >>>> >>>> SYNOPSIS >>>> #include >>>> >>>> void cv_init(kcondvar_t *cvp, char *name, kcv_type_t type, void >>>> *arg); >>>> >>>> void cv_destroy(kcondvar_t *cvp); >>>> >>>> void cv_wait(kcondvar_t *cvp, kmutex_t *mp); >>>> >>>> void cv_signal(kcondvar_t *cvp); >>>> >>>> void cv_broadcast(kcondvar_t *cvp); >>>> >>>> int cv_wait_sig(kcondvar_t *cvp, kmutex_t *mp); >>>> >>>> clock_t cv_timedwait(kcondvar_t *cvp, kmutex_t *mp, clock_t >>>> timeout); >>>> >>>> clock_t cv_timedwait_sig(kcondvar_t *cvp, kmutex_t *mp, clock_t >>>> timeout); >>>> >>>> | clock_t cv_reltimedwait(kcondvar_t *cvp, kmutex_t *mp, clock_t >>>> delta, >>>> | time_res_t resolution); >>>> >>>> | clock_t cv_reltimedwait_sig(kcondvar_t *cvp, kmutex_t *mp, >>>> clock_t delta, >>>> | time_res_t resolution); >>>> >>>> INTERFACE LEVEL >>>> Solaris DDI specific (Solaris DDI). >>>> >>>> PARAMETERS >>>> cvp A pointer to an abstract data type kcondvar_t. >>>> >>>> mp A pointer to a mutual exclusion lock (kmutex_t), >>>> initialized by mutex_init(9F) and held by the >>>> caller. >>>> >>>> name Descriptive string. This is obsolete and should >>>> be NULL. (Non-NULL strings are legal, but they're >>>> a waste of kernel memory.) >>>> >>>> SunOS 5.11 Last change: 02 Aug 2009 1 >>>> >>>> Kernel Functions for Drivers condvar(9F) >>>> >>>> type The constant CV_DRIVER. >>>> >>>> arg A type-specific argument, drivers should pass arg >>>> as NULL. >>>> >>>> timeout A time, in absolute ticks since boot, when >>>> cv_timedwait() or cv_timedwait_sig() should >>>> return. >>>> >>>> | delta A time, in relative ticks, when cv_reltimedwait() >>>> | or cv_reltimedwait_sig() should return. >>>> | >>>> | resolution A flag that specifies how accurately the relative >>>> | time interval should be. Possible values are >>>> | TR_NANOSEC, TR_MICROSEC, TR_MILLISEC, TR_SEC or >>>> | TR_CLOCK_TICK, the former indicating that the interval >>>> | should be aligned to system clock ticks. This >>>> | information allows the system to anticipate or >>>> | deffer the timeout expiration in order to batch process >>>> | similarly expiring events. Allowing the system to >>>> | stay idle for longer periods of time and enhance >>>> | its power efficiency. >>>> >>>> >>>> DESCRIPTION >>>> Condition variables are a standard form of thread synchroni- >>>> zation. They are designed to be used with mutual exclusion >>>> locks (mutexes). The associated mutex is used to ensure that >>>> a condition can be checked atomically and that the thread >>>> can block on the associated condition variable without miss- >>>> ing either a change to the condition or a signal that the >>>> condition has changed. Condition variables must be initial- >>>> ized by calling cv_init(), and must be deallocated by cal- >>>> ling cv_destroy(). >>>> >>>> The usual use of condition variables is to check a condition >>>> (for example, device state, data structure reference count, >>>> etc.) while holding a mutex which keeps other threads from >>>> changing the condition. If the condition is such that the >>>> thread should block, cv_wait() is called with a related con- >>>> dition variable and the mutex. At some later point in time, >>>> another thread would acquire the mutex, set the condition >>>> such that the previous thread can be unblocked, unblock the >>>> previous thread with cv_signal() or cv_broadcast(), and then >>>> release the mutex. >>>> >>>> cv_wait() suspends the calling thread and exits the mutex >>>> atomically so that another thread which holds the mutex can- >>>> not signal on the condition variable until the blocking >>>> thread is blocked. Before returning, the mutex is reac- >>>> quired. >>>> >>>> cv_signal() signals the condition and wakes one blocked >>>> thread. All blocked threads can be unblocked by calling >>>> cv_broadcast(). cv_signal() and cv_broadcast() can be called >>>> by a thread even if it does not hold the mutex passed into >>>> cv_wait(), though holding the mutex is necessary to ensure >>>> predictable scheduling. >>>> >>>> SunOS 5.11 Last change: 02 Aug 2009 2 >>>> >>>> Kernel Functions for Drivers condvar(9F) >>>> >>>> The function cv_wait_sig() is similar to cv_wait() but >>>> returns 0 if a signal (for example, by kill(2)) is sent to >>>> the thread. In any case, the mutex is reacquired before >>>> returning. >>>> >>>> The function cv_timedwait() is similar to cv_wait(), except >>>> that it returns -1 without the condition being signaled >>>> after the timeout time has been reached. >>>> >>>> The function cv_timedwait_sig() is similar to cv_timedwait() >>>> and cv_wait_sig(), except that it returns -1 without the >>>> condition being signaled after the timeout time has been >>>> reached, or 0 if a signal (for example, by kill(2)) is sent >>>> to the thread. >>>> >>>> For both cv_timedwait() and cv_timedwait_sig(), time is in >>>> absolute clock ticks since the last system reboot. The >>>> current time may be found by calling ddi_get_lbolt(9F). >>>> >>>> | The cv_reltimedwait() function is similar to cv_timedwait(), >>>> | except that it takes a relative time value as argument and >>>> | it also takes an additional argument to specify the accuracy >>>> | of such interval. cv_reltimedwait_sig() is analogous to >>>> | cv_timedwait_sig(), but takes the same arguments as >>>> | cv_reltimedwait(). >>>> >>>> RETURN VALUES >>>> 0 For cv_wait_sig(), cv_timedwait_sig() and >>>> cv_reltimedwait_sig() >>>> indicates >>>> that the condition was not necessarily signaled and >>>> the function returned because a signal (as in >>>> kill(2)) was pending. >>>> >>>> | -1 For cv_timedwait(), cv_timedwait_sig(), >>>> | cv_reltimedwait() and cv_reltimedwait_sig() indicates >>>> that the condition was not necessarily signaled and >>>> the function returned because the timeout time was >>>> reached. >>>> >>>> | >0 For cv_wait_sig(), cv_timedwait(), cv_timedwait_sig(), >>>> | cv_reltimedwait() or cv_reltimedwait_sig() >>>> | indicates that the condition was >>>> met and the function returned due to a call to >>>> cv_signal() or cv_broadcast(), or due to a prema- >>>> ture wakeup (see NOTES). >>>> >>>> CONTEXT >>>> These functions can be called from user, kernel or interrupt >>>> context. In most cases, however, cv_wait(), cv_timedwait(), >>>> | cv_wait_sig(), cv_timedwait_sig(), cv_reltimedwait() and >>>> | cv_reltimedwait_sig() >>>> should not be called >>>> from interrupt context, and cannot be called from a high- >>>> level interrupt context. >>>> >>>> If cv_wait(), cv_timedwait(), cv_wait_sig(), >>>> | cv_timedwait_sig(), cv_reltimedwait() or cv_reltimedwait_sig() >>>> | are used from interrupt context, lower- >>>> >>>> SunOS 5.11 Last change: 02 Aug 2009 3 >>>> >>>> Kernel Functions for Drivers condvar(9F) >>>> >>>> priority interrupts will not be serviced during the wait. >>>> This means that if the thread that will eventually perform >>>> the wakeup becomes blocked on anything that requires the >>>> lower-priority interrupt, the system will hang. >>>> >>>> For example, the thread that will perform the wakeup may >>>> need to first allocate memory. This memory allocation may >>>> require waiting for paging I/O to complete, which may >>>> require a lower-priority disk or network interrupt to be >>>> serviced. In general, situations like this are hard to >>>> predict, so it is advisable to avoid waiting on condition >>>> variables or semaphores in an interrupt context. >>>> >>>> EXAMPLES >>>> Example 1 Waiting for a Flag Value in a Driver's Unit >>>> >>>> Here the condition being waited for is a flag value in a >>>> driver's unit structure. The condition variable is also in >>>> the unit structure, and the flag word is protected by a >>>> mutex in the unit structure. >>>> >>>> mutex_enter(&un->un_lock); >>>> while (un->un_flag & UNIT_BUSY) >>>> cv_wait(&un->un_cv, &un->un_lock); >>>> un->un_flag |= UNIT_BUSY; >>>> mutex_exit(&un->un_lock); >>>> >>>> Example 2 Unblocking Threads Blocked by the Code in Example >>>> 1 >>>> >>>> At some later point in time, another thread would execute >>>> the following to unblock any threads blocked by the above >>>> code. >>>> >>>> mutex_enter(&un->un_lock); >>>> un->un_flag &= ~UNIT_BUSY; >>>> cv_broadcast(&un->un_cv); >>>> mutex_exit(&un->un_lock); >>>> >>>> NOTES >>>> | It is possible for cv_wait(), cv_wait_sig(), cv_timedwait(), >>>> | cv_timedwait_sig(), cv_reltimedwait() and cv_reltimedwait_sig() >>>> | to return prematurely, that is, not >>>> due to a call to cv_signal() or cv_broadcast(). This occurs >>>> most commonly in the case of cv_wait_sig(), >>>> >>>> SunOS 5.11 Last change: 02 Aug 2009 4 >>>> >>>> Kernel Functions for Drivers condvar(9F) >>>> >>>> | cv_timedwait_sig() and cv_reltimedwait_sig() when the thread >>>> | is stopped and restarted >>>> by job control signals or by a debugger, but can happen in >>>> other cases as well, even for cv_wait(). Code that calls >>>> these functions must always recheck the reason for blocking >>>> and call again if the reason for blocking is still true. >>>> >>>> | If your driver needs to wait on behalf of processes that >>>> | have real-time constraints, use cv_timedwait() or >>>> cv_reltimedwait() >>>> | rather than >>>> delay(9F). The delay() function calls timeout(9F), which can >>>> be subject to priority inversions. >>>> >>>> Not all threads can receive signals from user level >>>> processes. In cases where such reception is impossible (such >>>> as during execution of close(9E) due to exit(2)), >>>> cv_wait_sig() behaves as cv_wait(), cv_timedwait_sig() >>>> | behaves as cv_timedwait() and cv_reltimedwait_sig() behaves as >>>> | cv_reltimedwait(). >>>> To avoid unkillable processes, >>>> users of these functions may need to protect against waiting >>>> indefinitely for events that might not occur. The >>>> ddi_can_receive_sig(9F) function is provided to detect when >>>> signal reception is possible. >>>> >>>> SEE ALSO >>>> kill(2), ddi_can_receive_sig(9F), ddi_get_lbolt(9F), >>>> | ddi_get_lbolt64(9F), mutex(9F), mutex_init(9F) >>>> >>>> Writing Device Drivers >>>> >>>> SunOS 5.11 Last change: 02 Aug 2009 5 >>>> >>> >> > From glenn.skinner@sun.com Tue Sep 1 15:37:03 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n81Mb3ZD025461 for ; Tue, 1 Sep 2009 15:37:03 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n81Mb2ii002650 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 1 Sep 2009 15:37:03 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPB00805DHQLI00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Sep 2009 15:37:02 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPB00D7FDHQD290@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Sep 2009 15:37:02 -0700 (PDT) Received: from ivrel.sfbay.sun.com (ivrel.SFBay.Sun.COM [129.146.74.76]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n81Mb1Na045105; Tue, 01 Sep 2009 15:37:01 -0700 (PDT) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.14.3+Sun/8.14.3) with SMTP id n81MTVAP016398; Tue, 01 Sep 2009 15:29:31 -0700 (PDT) Date: Tue, 01 Sep 2009 15:29:31 -0700 (PDT) From: Glenn Skinner Subject: Re: 2009/396 [Tickless Kernel Architecture / lbolt decoupling] To: PSARC-ext@sun.com, Rafael.Vanoni@sun.com, Jerry.Gilliam@sun.com Cc: Eric.Saxe@sun.com, Madhavan.Venkataraman@sun.com, Steve.Sistare@sun.com Reply-to: Glenn Skinner Message-id: <200909012229.n81MTVAP016398@ivrel.sfbay.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: Bf1cZrBw4nj/H3dzXMA2zw== X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 4073 Date: Tue, 01 Sep 2009 14:22:45 -0700 From: Jerry Gilliam Subject: Re: PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009] I am sponsoring the following fast-track on behalf of Rafael Vanoni, with a time-out of 09/09/2009. The project desires minor/major binding, plus micro/patch binding for one interface, as specified. Garrett asked whether this was suitable for a fast track or whether its scope exceeds what's appropriate for a fast track. To me, the _architecture_ of the case is clear, confined, and qualifies for fast track review. (There are implied logistical issues in getting potentially affected parties to take notice of the case, but that's not architecture.) +1 from me, with one quibble (see the comment at the left margin below). In the documentation updates section, we have: ... Updates to condvar(9f): ---------------------- Kernel Functions for Drivers condvar(9F) NAME condvar, cv_init, cv_destroy, cv_wait, cv_signal, cv_broadcast, cv_wait_sig, cv_timedwait, cv_timedwait_sig, cv_reltimedwait, cv_reltimedwait_sig - condition variable routines SYNOPSIS #include void cv_init(kcondvar_t *cvp, char *name, kcv_type_t type, void *arg); void cv_destroy(kcondvar_t *cvp); void cv_wait(kcondvar_t *cvp, kmutex_t *mp); void cv_signal(kcondvar_t *cvp); void cv_broadcast(kcondvar_t *cvp); int cv_wait_sig(kcondvar_t *cvp, kmutex_t *mp); clock_t cv_timedwait(kcondvar_t *cvp, kmutex_t *mp, clock_t timeout); clock_t cv_timedwait_sig(kcondvar_t *cvp, kmutex_t *mp, clock_t timeout); | clock_t cv_reltimedwait(kcondvar_t *cvp, kmutex_t *mp, clock_t delta, | time_res_t resolution); | clock_t cv_reltimedwait_sig(kcondvar_t *cvp, kmutex_t *mp, clock_t delta, | time_res_t resolution); INTERFACE LEVEL Solaris DDI specific (Solaris DDI). PARAMETERS cvp A pointer to an abstract data type kcondvar_t. mp A pointer to a mutual exclusion lock (kmutex_t), initialized by mutex_init(9F) and held by the caller. name Descriptive string. This is obsolete and should be NULL. (Non-NULL strings are legal, but they're a waste of kernel memory.) type The constant CV_DRIVER. arg A type-specific argument, drivers should pass arg as NULL. timeout A time, in absolute ticks since boot, when cv_timedwait() or cv_timedwait_sig() should return. | delta A time, in relative ticks, when cv_reltimedwait() | or cv_reltimedwait_sig() should return. | | resolution A flag that specifies how accurately the relative | time interval should be. Possible values are | TR_NANOSEC, TR_MICROSEC, TR_MILLISEC, TR_SEC or | TR_CLOCK_TICK, the former indicating that the interval | should be aligned to system clock ticks. This | information allows the system to anticipate or | deffer the timeout expiration in order to batch process | similarly expiring events. Allowing the system to | stay idle for longer periods of time and enhance | its power efficiency. Please reword the second sentence of the "resolution" paragraph above to make it clear that TR_CLOCK_TICK is the value that indicates alignment to system clock ticks. ("Former" and "latter" are ill-defined when there are more than two alternatives, and "former" is usually taken to mean the first-appearing of a pair of alternatives, at least in the American dialect of English.) (I did say that it was a quibble...) -- Glenn From Rafael.Vanoni@sun.com Tue Sep 1 15:39:25 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n81MdOWr025544 for ; Tue, 1 Sep 2009 15:39:25 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n81MdL33000972 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 1 Sep 2009 23:39:23 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPB00003DLMND00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Sep 2009 15:39:22 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPB00KZZDLMEB20@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Sep 2009 15:39:22 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n81MdMBD021013 for ; Tue, 01 Sep 2009 15:39:22 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPB00000DGKAX00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Sep 2009 15:39:22 -0700 (PDT) Received: from [129.146.229.172] ([unknown] [129.146.229.172]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPB00KQ5DLLT010@fe-sfbay-10.sun.com>; Tue, 01 Sep 2009 15:39:21 -0700 (PDT) Date: Tue, 01 Sep 2009 15:39:21 -0700 From: Rafael Vanoni Subject: Re: PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009] In-reply-to: <4a9d9927./ZRbLvLmxk+UnZdT%Joerg.Schilling@fokus.fraunhofer.de> Sender: Rafael.Vanoni@sun.com To: Joerg Schilling Cc: PSARC-ext@sun.com, Jerry.Gilliam@sun.com, Steve.Sistare@sun.com, Madhavan.Venkataraman@sun.com, Eric.Saxe@sun.com Message-id: <4A9DA299.1070406@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <4A9D90A5.8030905@sun.com> <4a9d9927./ZRbLvLmxk+UnZdT%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: Thunderbird 2.0.0.22 (X11/20090804) Status: RO Content-Length: 1145 Joerg Schilling wrote: > Jerry Gilliam wrote: > >> 2. Project Summary >> 2.1. Project Description: >> The tickless project aims at implementing the services provided by the >> clock cyclic in an event driven fashion. The first sub-project is the >> decoupling of the lbolt and lbolt64 variables from clock(). These two >> variables are incremented at each firing of the clock cyclic and provide >> a time reference to the system. They are being replaced by two routines >> that are backed by gethrtime(), the existing ddi_get_lbolt() and >> the new ddi_get_lbolt64(), introduced as a migration path for existing >> non-DDI compliant consumers. > > If this results in being able to sleep with less than 10 ms granularity without > setting a high-res tick, you get many + from me! > > Jörg > Unfortunately, no. That enhancement is outside the scope of this project. As more pieces of the tickless project integrate, the added overhead of having a higher rate clock will be reduced. Which I imagine will be beneficial for everyone. Thanks, Rafael From Rafael.Vanoni@sun.com Tue Sep 1 15:40:35 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n81MeYMM025650 for ; Tue, 1 Sep 2009 15:40:34 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n81MeTqV001630 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 1 Sep 2009 23:40:33 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPB00C09DNJXN00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Sep 2009 16:40:31 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPB005KCDNIC640@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Sep 2009 16:40:31 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n81MePop021156; Tue, 01 Sep 2009 15:40:25 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPB00400DJS5O00@fe-sfbay-09.sun.com>; Tue, 01 Sep 2009 15:40:22 -0700 (PDT) Received: from [129.146.229.172] ([unknown] [129.146.229.172]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPB008HSDN9Q7D0@fe-sfbay-09.sun.com>; Tue, 01 Sep 2009 15:40:22 -0700 (PDT) Date: Tue, 01 Sep 2009 15:40:21 -0700 From: Rafael Vanoni Subject: Re: 2009/396 [Tickless Kernel Architecture / lbolt decoupling] In-reply-to: <200909012229.n81MTVAP016398@ivrel.sfbay.sun.com> Sender: Rafael.Vanoni@sun.com To: Glenn Skinner Cc: PSARC-ext@sun.com, Jerry.Gilliam@sun.com, Eric.Saxe@sun.com, Madhavan.Venkataraman@sun.com, Steve.Sistare@sun.com Message-id: <4A9DA2D5.7050806@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909012229.n81MTVAP016398@ivrel.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090804) Status: RO Content-Length: 4341 Glenn Skinner wrote: > Date: Tue, 01 Sep 2009 14:22:45 -0700 > From: Jerry Gilliam > Subject: Re: PSARC/2009/396 Tickless Kernel Architecture / lbolt > decoupling [Fasttrack timeout 09/09/2009] > > I am sponsoring the following fast-track on behalf of Rafael Vanoni, > with a time-out of 09/09/2009. The project desires > minor/major binding, plus micro/patch binding for one > interface, as specified. > > Garrett asked whether this was suitable for a fast track or whether > its scope exceeds what's appropriate for a fast track. > > To me, the _architecture_ of the case is clear, confined, and qualifies > for fast track review. (There are implied logistical issues in > getting potentially affected parties to take notice of the case, but > that's not architecture.) > > +1 from me, with one quibble (see the comment at the left margin > below). > > In the documentation updates section, we have: > > ... > Updates to condvar(9f): > ---------------------- > > Kernel Functions for Drivers condvar(9F) > > NAME > condvar, cv_init, cv_destroy, cv_wait, cv_signal, > cv_broadcast, cv_wait_sig, cv_timedwait, cv_timedwait_sig, > cv_reltimedwait, cv_reltimedwait_sig - condition variable > routines > > SYNOPSIS > #include > > void cv_init(kcondvar_t *cvp, char *name, kcv_type_t type, void *arg); > > void cv_destroy(kcondvar_t *cvp); > > void cv_wait(kcondvar_t *cvp, kmutex_t *mp); > > void cv_signal(kcondvar_t *cvp); > > void cv_broadcast(kcondvar_t *cvp); > > int cv_wait_sig(kcondvar_t *cvp, kmutex_t *mp); > > clock_t cv_timedwait(kcondvar_t *cvp, kmutex_t *mp, clock_t timeout); > > clock_t cv_timedwait_sig(kcondvar_t *cvp, kmutex_t *mp, clock_t timeout); > > | clock_t cv_reltimedwait(kcondvar_t *cvp, kmutex_t *mp, clock_t delta, > | time_res_t resolution); > > | clock_t cv_reltimedwait_sig(kcondvar_t *cvp, kmutex_t *mp, clock_t delta, > | time_res_t resolution); > > INTERFACE LEVEL > Solaris DDI specific (Solaris DDI). > > PARAMETERS > cvp A pointer to an abstract data type kcondvar_t. > > mp A pointer to a mutual exclusion lock (kmutex_t), > initialized by mutex_init(9F) and held by the > caller. > > name Descriptive string. This is obsolete and should > be NULL. (Non-NULL strings are legal, but they're > a waste of kernel memory.) > > type The constant CV_DRIVER. > > arg A type-specific argument, drivers should pass arg > as NULL. > > timeout A time, in absolute ticks since boot, when > cv_timedwait() or cv_timedwait_sig() should > return. > > | delta A time, in relative ticks, when cv_reltimedwait() > | or cv_reltimedwait_sig() should return. > | > | resolution A flag that specifies how accurately the relative > | time interval should be. Possible values are > | TR_NANOSEC, TR_MICROSEC, TR_MILLISEC, TR_SEC or > | TR_CLOCK_TICK, the former indicating that the interval > | should be aligned to system clock ticks. This > | information allows the system to anticipate or > | deffer the timeout expiration in order to batch process > | similarly expiring events. Allowing the system to > | stay idle for longer periods of time and enhance > | its power efficiency. > > Please reword the second sentence of the "resolution" paragraph above > to make it clear that TR_CLOCK_TICK is the value that indicates > alignment to system clock ticks. ("Former" and "latter" are > ill-defined when there are more than two alternatives, and "former" is > usually taken to mean the first-appearing of a pair of alternatives, > at least in the American dialect of English.) > > (I did say that it was a quibble...) > > -- Glenn > Will do. Thank you. Rafael From Nicolas.Williams@sun.com Tue Sep 1 15:53:46 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n81MrkQQ026166 for ; Tue, 1 Sep 2009 15:53:46 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n81MrhjI008476; Tue, 1 Sep 2009 15:53:44 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPB00E05E9KCT00@brm-avmta-1.central.sun.com>; Tue, 01 Sep 2009 16:53:44 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPB005DQE9KBV50@brm-avmta-1.central.sun.com>; Tue, 01 Sep 2009 16:53:44 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n81MoKDN008650; Tue, 01 Sep 2009 17:50:20 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n81MoKW8008649; Tue, 01 Sep 2009 17:50:20 -0500 (CDT) Date: Tue, 01 Sep 2009 17:50:20 -0500 From: Nicolas Williams Subject: Re: PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009] In-reply-to: <4A9DA1A7.2060308@sun.com> To: Rafael Vanoni Cc: "Garrett D'Amore" , Jerry Gilliam , PSARC-ext@sun.com, Eric Saxe , Madhavan.Venkataraman@sun.com, Steven Sistare Message-id: <20090901225020.GA1033@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4A9D90A5.8030905@sun.com> <4A9D94BD.8040000@sun.com> <4A9D9657.9010104@sun.com> <4A9D9F59.50600@sun.com> <4A9DA1A7.2060308@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1451 On Tue, Sep 01, 2009 at 03:35:19PM -0700, Rafael Vanoni wrote: > Garrett D'Amore wrote: > >Rafael Vanoni wrote: > >>There are still many consumers of cv_timedwait who need to pass in an > >>absolute time. cv_wait serves a similar purpose but without the timed > >>component, so it's functionality doesn't overlap with cv_reltimedwait(). > > > >Really? In device drivers? Because darn near every time I've used > >cv_timedwait (and I've used it a *lot* over my career), what I really > >wanted was a relative time (usually for a timeout.) I can't think of > >any reason in normal kernel code why you'd want an *absolute* time. > >(Apart from the kernel proper, where I can see absolute times being > >useful for wall clock kinds of things.) > > Yes, both in kernel and drivers (iwh and iwk2, for instance). I can come > up with a list if you're interested. Er, iwh and iwk2 do this: clk = ddi_get_lbolt() + drv_usectohz(1000000); /* wait loading run_text until completed or timeout */ while (!(sc->sc_flags & IWH_F_PUT_SEG)) { if (cv_timedwait(&sc->sc_put_seg_cv, &sc->sc_glock, clk) < 0) { break; } } Looks like a candidate for cv_reltimedwait(). That said, I can see wall-clock time waits in third-party modules (think of things like OpenAFS). But then, one can always turn those into reltimedwaits [except in real-time contexts?]. Nico -- From edward.pilatowicz@sun.com Tue Sep 1 15:55:48 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n81MtmGH026442 for ; Tue, 1 Sep 2009 15:55:48 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n81MtlcD022026 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 1 Sep 2009 15:55:48 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPB00E15ECZLO00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Sep 2009 16:55:47 -0600 (MDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPB005HWECXBZ50@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Sep 2009 16:55:46 -0600 (MDT) Received: from eng.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.63]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n81MtiN9054684; Tue, 01 Sep 2009 15:55:44 -0700 (PDT) Date: Tue, 01 Sep 2009 15:55:44 -0700 From: Edward Pilatowicz Subject: Re: PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009] In-reply-to: <4A9D90A5.8030905@sun.com> To: Jerry Gilliam Cc: PSARC-ext@sun.com, Rafael Vanoni , Eric Saxe , Madhavan.Venkataraman@sun.com, Steven Sistare Message-id: <20090901225544.GF965427@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4A9D90A5.8030905@sun.com> User-Agent: Mutt/1.5.19 (2009-01-05) Status: RO Content-Length: 23491 hey rafael, for the new cv_* functions the delta is still specified by a clock_t, which iirc is still subject to the value of "hz". many driver writers incorrectly assume that "hz" is always 100. hence when some brave/foolish person comes along and sets "hires_tick" or a custom "hz" value, things break. getting to my point, if we're introducing new interfaces to allow driver writers to simplify their drivers, perhaps we could move away from having them deal with clock_t values all together? did you consider creating the new interfaces to allow the caller to simply specify the requested delta directly in NANOSEC/MICROSEC/MILLISEC/SEC values? ed On Tue, Sep 01, 2009 at 02:22:45PM -0700, Jerry Gilliam wrote: > > I am sponsoring the following fast-track on behalf of Rafael Vanoni, > with a time-out of 09/09/2009. The project desires > minor/major binding, plus micro/patch binding for one > interface, as specified. > > ------------------------------------- > > Template Version: @(#)onepager.txt 1.35 07/11/07 SMI > Copyright 2007 Sun Microsystems > > 1. Introduction > 1.1. Project/Component Working Name: > Tickless Kernel Architecture / lbolt decoupling > > 1.2. Name of Document Author/Supplier: > Rafael Vanoni Polanczyk (rafael.vanoni@sun.com) > > 1.3. Date of This Document: > 08/04/09 > > 1.3.1. Date this project was conceived: > 07/01/09 > > 1.4. Name of Major Document Customer(s)/Consumer(s): > 1.4.1. The PAC or CPT you expect to review your project: > Solaris PAC > 1.4.2. The ARC(s) you expect to review your project: > 1.4.3. The Director/VP who is "Sponsoring" this project: > Greg.Lavender@Sun.COM > 1.4.4. The name of your business unit: > Systems > > 1.5. Email Aliases: > 1.5.1. Responsible Manager: darrin.johnson@sun.com > 1.5.2. Responsible Engineer: rafael.vanoni@sun.com > 1.5.3. Marketing Manger: mike.mulkey@sun.com > 1.5.4. Interest List: tickless-dev@opensolaris.org > > > 2. Project Summary > 2.1. Project Description: > The tickless project aims at implementing the services provided by the > clock cyclic in an event driven fashion. The first sub-project is the > decoupling of the lbolt and lbolt64 variables from clock(). These two > variables are incremented at each firing of the clock cyclic and provide > a time reference to the system. They are being replaced by two routines > that are backed by gethrtime(), the existing ddi_get_lbolt() and > the new ddi_get_lbolt64(), introduced as a migration path for existing > non-DDI compliant consumers. > > This project also presents a solution to minimize the usage of the DDI > lbolt routines through new interfaces, and a method to prevent any > performance impact of migrating inexpensive references to variables, to > calling of routines. These are described in detail on section 4.1. > > > 4. Technical Description: > 4.1. Details: > lbolt and lbolt64 variables will be replaced by two routines, > ddi_get_lbolt() and ddi_get_lbolt64(), which are backed by a hardware > counter to provide the same service in en event driven way. > > One of the major consumers of the lbolt service are the cv_timedwait() > and cv_timedwait_sig() routines, which require lbolt to form one of its > arguments (an absolute value of time) and once again internally to > decompose it into a relative time. This project is introducing two new > routines, cv_reltimedwait() and cv_reltimedwait_sig() which will perform > the same service of the previously mentioned routines but simply > receiving a relative time, and not requiring lbolt at all. These new > routines will also have a new argument of type time_res_t to inform > the underlying timeout system as to how accurately the given timeout > must expire. This will allow the kernel to anticipate or defer such > timeouts when possible, allowing the system to stay idle for longer > periods of time. > > Some consumers of the lbolt and lbolt64 variables may have inexplicit > dependencies on the cheapness of reading a memory position that will be > exposed when migrated to a gethrtime() backed routine. In such cases > migrating references to lbolt and lbolt64 to ddi_get_lbolt() and > ddi_get_lbolt64() will have a negative performance impact. To address > this case, our project will perform the lbolt service in an hybrid way, > switching from event to cyclic driven when the DDI lbolt routines are > being heavily used. This cyclic mode will reprogram a timer that will > expire at each clock tick and increment an internal (lbolt like) > variable and return its value to the consumer. This cyclic will only > be activated during periods of heavy load, and will switch itself off > when the activity subsides. > > The decision to remove the lbolt and lbolt64 variables was made during > design review, and a consensus was reached on the basis that, since > we're reaching the end of a major release, this is the right moment to > obsolete these. The side effects and cost of maintaining such symbols > outweigh the benefits. However, this decision can be re-evaluated in > case the negative impact on 3rd party modules during the development > release is greater than expected. We're working with ISV and RPE to > minimize the impact pro-actively. > > 4.2. Bug/RFE Number(s): > 6860030 tickless clock requires a clock() decoupled lbolt / lbolt64 > > 4.5. Interfaces: > This project is adding the following interfaces to the DDI: > > int64_t ddi_get_lbolt64(void); > > clock_t cv_reltimedwait(kcondvar_t *cvp, kmutex_t *mp, clock_t delta, > time_res_t res); > > clock_t cv_reltimedwait_sig(kcondvar_t *cvp, kmutex_t *mp, clock_t > delta, time_res_t res); > > With time_res_t defined as > > enum time_res { > TR_NANOSEC, > TR_MICROSEC, > TR_MILLISEC, > TR_SEC, > TR_CLOCK_TICK, > TR_COUNT > }; > > typedef enum time_res time_res_t; > > In addition to that, the lbolt and lbolt64 variables (which are > *private* symbols known to be used by non-DDI compliant modules) are > being removed. 3rd party modules that are not brought up to speed will > fail to load. > > In summary: > > Interface Commitment Comments > ----------------------------------------------------------------------- > ddi_get_lbolt64() Public/DDI return lbolt64 > cv_reltimedwait(9F) Public/DDI cv_timedwait(9f), relative time > cv_reltimedwait_sig(9F) Public/DDI cv_timedwait_sig(9F), relative time > lbolt Obsolete commonly referenced kernel symbol > lbolt64 Obsolete commonly referenced kernel symbol > > We also plan on back porting the ddi_get_lbolt64() interface to Solaris > 10 Update 9 to extend the migration path for S10 users who would like > to update their modules before moving to Solaris Nevada or the next > version of Solaris. These users already have ddi_get_lbolt() but > currently lack the 64 bits version of it. Such back port will have > patch release binding. > > > 4.6. Doc Impact: > 6868417 updates for tickless kernel/lbolt decoupling (6860030) > > Updates to the 'Writing Device Drivers' document are necessary, the > project team is in contact with the documentation group to address > these. > > > 5. Reference Documents: > This project is being developed through OpenSolaris, our project pages > and alias contain all the necessary information: > http://opensolaris.org/os/project/tickless/ > http://opensolaris.org/os/project/tickless/tasks/lbolt/ > tickless-dev@opensolaris.org > > > 6. Resources and Schedule: > 6.5. ARC review type: Fast track > 6.6. ARC Exposure: open > > > > > > Updates to existing man pages: > ------------------------------ > > drv_getparm.9f > > PARAMETERS > ... > > LBOLT Read the value of lbolt. lbolt is a clock_t that | > represents the number of clock ticks since system | > boot. No special treatment is applied when | > this value overflows the maximum value of the > signed integral type clock_t. When this occurs, > its value will be negative, and its magnitude will > be decreasing until it again passes zero. It can > ... > > > > > drv_hztousec.9f > > DESCRIPTION > The drv_hztousec() function converts into microseconds the > time expressed by hertz, which is in system clock ticks. > > The length of time the system has been up since boot can be | > retrieved by calling ddi_get_lbolt(9F), which will return a | > value of type clock_t containing the number of clock ticks > since boot. Drivers often use this value before and after an > I/O request to measure the amount of time it took the device to > process the request. The drv_hztousec() function can be used > by the driver to convert the reading from clock ticks to a > known unit of time. > > > > > Intro.9f > > Kernel Functions for Drivers Intro(9F) > > ddi_get_instance Solaris DDI > ddi_get_kt_did Solaris DDI > ddi_get_lbolt Solaris DDI > ddi_get_lbolt64 Solaris DDI + > ddi_get_name Solaris DDI > ... > > > > > Updated ddi_get_lbolt.9f: > ------------------------- > > Kernel Functions for Drivers ddi_get_lbolt(9F) > > NAME > ddi_get_lbolt - returns the number of clock ticks since boot | > > SYNOPSIS > #include > #include > #include > > clock_t ddi_get_lbolt(void); > > INTERFACE LEVEL > Solaris DDI specific (Solaris DDI). > > DESCRIPTION > ddi_get_lbolt() returns a value that represents the number | > of clock ticks since the system booted. This value is | > used as a counter or timer inside the system kernel. > The tick frequency can be determined by using drv_usectohz(9F) > which converts microseconds into clock ticks. > > > RETURN VALUES > ddi_get_lbolt() returns the number of clock ticks since boot | > in clock_t type. > > CONTEXT > This routine can be called from any context. > > SEE ALSO > ddi_get_lbolt64(9F), ddi_get_time(9F), drv_getparm(9F), > drv_usectohz(9F) > > > > > New man page for ddi_get_lbolt64(): > ----------------------------------- > > Kernel Functions for Drivers ddi_get_lbolt64(9F) > > NAME > ddi_get_lbolt64 - returns the number of clock ticks since boot > in int64_t type > > SYNOPSIS > #include > #include > #include > > int64_t ddi_get_lbolt64(void); > > INTERFACE LEVEL > Solaris DDI specific (Solaris DDI). > > DESCRIPTION > ddi_get_lbolt64() returns a value that represents the number > of clock ticks since the system booted. This value is > used as a counter or timer inside the system kernel. It is > essentially the same value returned by ddi_get_lbolt(9F), but in a > longer data type that will not wrap for 2.9 billion years. > > RETURN VALUES > ddi_get_lbolt64() returns the number of clock ticks since boot > in int64_t type. > > CONTEXT > This routine can be called from any context. > > SEE ALSO > ddi_get_lbolt(9F), ddi_get_time(9F) > > Writing Device Drivers > > STREAMS Programming Guide > > SunOS 5.11 Last change: 29 Jul 2009 1 > > > Updates to condvar(9f): > ---------------------- > > Kernel Functions for Drivers condvar(9F) > > NAME > condvar, cv_init, cv_destroy, cv_wait, cv_signal, > cv_broadcast, cv_wait_sig, cv_timedwait, cv_timedwait_sig, > cv_reltimedwait, cv_reltimedwait_sig - condition variable > routines > > SYNOPSIS > #include > > void cv_init(kcondvar_t *cvp, char *name, kcv_type_t type, void *arg); > > void cv_destroy(kcondvar_t *cvp); > > void cv_wait(kcondvar_t *cvp, kmutex_t *mp); > > void cv_signal(kcondvar_t *cvp); > > void cv_broadcast(kcondvar_t *cvp); > > int cv_wait_sig(kcondvar_t *cvp, kmutex_t *mp); > > clock_t cv_timedwait(kcondvar_t *cvp, kmutex_t *mp, clock_t timeout); > > clock_t cv_timedwait_sig(kcondvar_t *cvp, kmutex_t *mp, clock_t timeout); > > | clock_t cv_reltimedwait(kcondvar_t *cvp, kmutex_t *mp, clock_t delta, > | time_res_t resolution); > > | clock_t cv_reltimedwait_sig(kcondvar_t *cvp, kmutex_t *mp, clock_t delta, > | time_res_t resolution); > > INTERFACE LEVEL > Solaris DDI specific (Solaris DDI). > > PARAMETERS > cvp A pointer to an abstract data type kcondvar_t. > > mp A pointer to a mutual exclusion lock (kmutex_t), > initialized by mutex_init(9F) and held by the > caller. > > name Descriptive string. This is obsolete and should > be NULL. (Non-NULL strings are legal, but they're > a waste of kernel memory.) > > SunOS 5.11 Last change: 02 Aug 2009 1 > > Kernel Functions for Drivers condvar(9F) > > type The constant CV_DRIVER. > > arg A type-specific argument, drivers should pass arg > as NULL. > > timeout A time, in absolute ticks since boot, when > cv_timedwait() or cv_timedwait_sig() should > return. > > | delta A time, in relative ticks, when cv_reltimedwait() > | or cv_reltimedwait_sig() should return. > | > | resolution A flag that specifies how accurately the relative > | time interval should be. Possible values are > | TR_NANOSEC, TR_MICROSEC, TR_MILLISEC, TR_SEC or > | TR_CLOCK_TICK, the former indicating that the interval > | should be aligned to system clock ticks. This > | information allows the system to anticipate or > | deffer the timeout expiration in order to batch process > | similarly expiring events. Allowing the system to > | stay idle for longer periods of time and enhance > | its power efficiency. > > > DESCRIPTION > Condition variables are a standard form of thread synchroni- > zation. They are designed to be used with mutual exclusion > locks (mutexes). The associated mutex is used to ensure that > a condition can be checked atomically and that the thread > can block on the associated condition variable without miss- > ing either a change to the condition or a signal that the > condition has changed. Condition variables must be initial- > ized by calling cv_init(), and must be deallocated by cal- > ling cv_destroy(). > > The usual use of condition variables is to check a condition > (for example, device state, data structure reference count, > etc.) while holding a mutex which keeps other threads from > changing the condition. If the condition is such that the > thread should block, cv_wait() is called with a related con- > dition variable and the mutex. At some later point in time, > another thread would acquire the mutex, set the condition > such that the previous thread can be unblocked, unblock the > previous thread with cv_signal() or cv_broadcast(), and then > release the mutex. > > cv_wait() suspends the calling thread and exits the mutex > atomically so that another thread which holds the mutex can- > not signal on the condition variable until the blocking > thread is blocked. Before returning, the mutex is reac- > quired. > > cv_signal() signals the condition and wakes one blocked > thread. All blocked threads can be unblocked by calling > cv_broadcast(). cv_signal() and cv_broadcast() can be called > by a thread even if it does not hold the mutex passed into > cv_wait(), though holding the mutex is necessary to ensure > predictable scheduling. > > SunOS 5.11 Last change: 02 Aug 2009 2 > > Kernel Functions for Drivers condvar(9F) > > The function cv_wait_sig() is similar to cv_wait() but > returns 0 if a signal (for example, by kill(2)) is sent to > the thread. In any case, the mutex is reacquired before > returning. > > The function cv_timedwait() is similar to cv_wait(), except > that it returns -1 without the condition being signaled > after the timeout time has been reached. > > The function cv_timedwait_sig() is similar to cv_timedwait() > and cv_wait_sig(), except that it returns -1 without the > condition being signaled after the timeout time has been > reached, or 0 if a signal (for example, by kill(2)) is sent > to the thread. > > For both cv_timedwait() and cv_timedwait_sig(), time is in > absolute clock ticks since the last system reboot. The > current time may be found by calling ddi_get_lbolt(9F). > > | The cv_reltimedwait() function is similar to cv_timedwait(), > | except that it takes a relative time value as argument and > | it also takes an additional argument to specify the accuracy > | of such interval. cv_reltimedwait_sig() is analogous to > | cv_timedwait_sig(), but takes the same arguments as > | cv_reltimedwait(). > > RETURN VALUES > 0 For cv_wait_sig(), cv_timedwait_sig() and cv_reltimedwait_sig() > indicates > that the condition was not necessarily signaled and > the function returned because a signal (as in > kill(2)) was pending. > > | -1 For cv_timedwait(), cv_timedwait_sig(), > | cv_reltimedwait() and cv_reltimedwait_sig() indicates > that the condition was not necessarily signaled and > the function returned because the timeout time was > reached. > > | >0 For cv_wait_sig(), cv_timedwait(), cv_timedwait_sig(), > | cv_reltimedwait() or cv_reltimedwait_sig() > | indicates that the condition was > met and the function returned due to a call to > cv_signal() or cv_broadcast(), or due to a prema- > ture wakeup (see NOTES). > > CONTEXT > These functions can be called from user, kernel or interrupt > context. In most cases, however, cv_wait(), cv_timedwait(), > | cv_wait_sig(), cv_timedwait_sig(), cv_reltimedwait() and > | cv_reltimedwait_sig() > should not be called > from interrupt context, and cannot be called from a high- > level interrupt context. > > If cv_wait(), cv_timedwait(), cv_wait_sig(), > | cv_timedwait_sig(), cv_reltimedwait() or cv_reltimedwait_sig() > | are used from interrupt context, lower- > > SunOS 5.11 Last change: 02 Aug 2009 3 > > Kernel Functions for Drivers condvar(9F) > > priority interrupts will not be serviced during the wait. > This means that if the thread that will eventually perform > the wakeup becomes blocked on anything that requires the > lower-priority interrupt, the system will hang. > > For example, the thread that will perform the wakeup may > need to first allocate memory. This memory allocation may > require waiting for paging I/O to complete, which may > require a lower-priority disk or network interrupt to be > serviced. In general, situations like this are hard to > predict, so it is advisable to avoid waiting on condition > variables or semaphores in an interrupt context. > > EXAMPLES > Example 1 Waiting for a Flag Value in a Driver's Unit > > Here the condition being waited for is a flag value in a > driver's unit structure. The condition variable is also in > the unit structure, and the flag word is protected by a > mutex in the unit structure. > > mutex_enter(&un->un_lock); > while (un->un_flag & UNIT_BUSY) > cv_wait(&un->un_cv, &un->un_lock); > un->un_flag |= UNIT_BUSY; > mutex_exit(&un->un_lock); > > Example 2 Unblocking Threads Blocked by the Code in Example > 1 > > At some later point in time, another thread would execute > the following to unblock any threads blocked by the above > code. > > mutex_enter(&un->un_lock); > un->un_flag &= ~UNIT_BUSY; > cv_broadcast(&un->un_cv); > mutex_exit(&un->un_lock); > > NOTES > | It is possible for cv_wait(), cv_wait_sig(), cv_timedwait(), > | cv_timedwait_sig(), cv_reltimedwait() and cv_reltimedwait_sig() > | to return prematurely, that is, not > due to a call to cv_signal() or cv_broadcast(). This occurs > most commonly in the case of cv_wait_sig(), > > SunOS 5.11 Last change: 02 Aug 2009 4 > > Kernel Functions for Drivers condvar(9F) > > | cv_timedwait_sig() and cv_reltimedwait_sig() when the thread > | is stopped and restarted > by job control signals or by a debugger, but can happen in > other cases as well, even for cv_wait(). Code that calls > these functions must always recheck the reason for blocking > and call again if the reason for blocking is still true. > > | If your driver needs to wait on behalf of processes that > | have real-time constraints, use cv_timedwait() or cv_reltimedwait() > | rather than > delay(9F). The delay() function calls timeout(9F), which can > be subject to priority inversions. > > Not all threads can receive signals from user level > processes. In cases where such reception is impossible (such > as during execution of close(9E) due to exit(2)), > cv_wait_sig() behaves as cv_wait(), cv_timedwait_sig() > | behaves as cv_timedwait() and cv_reltimedwait_sig() behaves as > | cv_reltimedwait(). > To avoid unkillable processes, > users of these functions may need to protect against waiting > indefinitely for events that might not occur. The > ddi_can_receive_sig(9F) function is provided to detect when > signal reception is possible. > > SEE ALSO > kill(2), ddi_can_receive_sig(9F), ddi_get_lbolt(9F), > | ddi_get_lbolt64(9F), mutex(9F), mutex_init(9F) > > Writing Device Drivers > > SunOS 5.11 Last change: 02 Aug 2009 5 From Rafael.Vanoni@sun.com Tue Sep 1 16:13:10 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n81ND9CC012603 for ; Tue, 1 Sep 2009 16:13:09 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n81ND3Nu010196 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Sep 2009 07:13:07 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPB00G05F5UEN00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Sep 2009 17:13:06 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPB005ZEF5TBZ60@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Sep 2009 17:13:05 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n81ND58o024375 for ; Tue, 01 Sep 2009 16:13:05 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPB00800EX1T600@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Sep 2009 16:13:05 -0700 (PDT) Received: from [129.146.229.172] ([unknown] [129.146.229.172]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPB00KH1F5QT0C0@fe-sfbay-10.sun.com>; Tue, 01 Sep 2009 16:13:02 -0700 (PDT) Date: Tue, 01 Sep 2009 16:13:02 -0700 From: Rafael Vanoni Subject: Re: PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009] In-reply-to: <20090901225020.GA1033@Sun.COM> Sender: Rafael.Vanoni@sun.com To: Nicolas Williams Cc: "Garrett D'Amore" , Jerry Gilliam , PSARC-ext@sun.com, Eric Saxe , Madhavan.Venkataraman@sun.com, Steven Sistare Message-id: <4A9DAA7E.9030008@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A9D90A5.8030905@sun.com> <4A9D94BD.8040000@sun.com> <4A9D9657.9010104@sun.com> <4A9D9F59.50600@sun.com> <4A9DA1A7.2060308@sun.com> <20090901225020.GA1033@Sun.COM> User-Agent: Thunderbird 2.0.0.22 (X11/20090804) Status: RO Content-Length: 1565 Nicolas Williams wrote: > On Tue, Sep 01, 2009 at 03:35:19PM -0700, Rafael Vanoni wrote: >> Garrett D'Amore wrote: >>> Rafael Vanoni wrote: >>>> There are still many consumers of cv_timedwait who need to pass in an >>>> absolute time. cv_wait serves a similar purpose but without the timed >>>> component, so it's functionality doesn't overlap with cv_reltimedwait(). >>> Really? In device drivers? Because darn near every time I've used >>> cv_timedwait (and I've used it a *lot* over my career), what I really >>> wanted was a relative time (usually for a timeout.) I can't think of >>> any reason in normal kernel code why you'd want an *absolute* time. >>> (Apart from the kernel proper, where I can see absolute times being >>> useful for wall clock kinds of things.) >> Yes, both in kernel and drivers (iwh and iwk2, for instance). I can come >> up with a list if you're interested. > > Er, iwh and iwk2 do this: > > clk = ddi_get_lbolt() + drv_usectohz(1000000); > > /* wait loading run_text until completed or timeout */ > while (!(sc->sc_flags & IWH_F_PUT_SEG)) { > if (cv_timedwait(&sc->sc_put_seg_cv, &sc->sc_glock, clk) < 0) { > break; > } > } > > Looks like a candidate for cv_reltimedwait(). It seemed that way to me before the first code reviewer (Madhavan) pointed out that with cv_reltimedwait() the timer would be reloaded with the same delta at each iteration - where it had originally specified an absolute time limit. Thanks, Rafael From Nicolas.Williams@sun.com Tue Sep 1 16:25:25 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n81NPOnj005802 for ; Tue, 1 Sep 2009 16:25:25 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n81NPCNJ027138; Wed, 2 Sep 2009 00:25:19 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPB00F01FQ6C400@nwk-avmta-1.sfbay.Sun.COM>; Tue, 01 Sep 2009 16:25:18 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPB00D4UFQ5D2D0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 01 Sep 2009 16:25:18 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n81NLrpm008695; Tue, 01 Sep 2009 18:21:53 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n81NLrDg008694; Tue, 01 Sep 2009 18:21:53 -0500 (CDT) Date: Tue, 01 Sep 2009 18:21:53 -0500 From: Nicolas Williams Subject: Re: PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009] In-reply-to: <4A9DAA7E.9030008@sun.com> To: Rafael Vanoni Cc: "Garrett D'Amore" , Jerry Gilliam , PSARC-ext@sun.com, Eric Saxe , Madhavan.Venkataraman@sun.com, Steven Sistare Message-id: <20090901232153.GD1033@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4A9D90A5.8030905@sun.com> <4A9D94BD.8040000@sun.com> <4A9D9657.9010104@sun.com> <4A9D9F59.50600@sun.com> <4A9DA1A7.2060308@sun.com> <20090901225020.GA1033@Sun.COM> <4A9DAA7E.9030008@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 554 On Tue, Sep 01, 2009 at 04:13:02PM -0700, Rafael Vanoni wrote: > Nicolas Williams wrote: > >Looks like a candidate for cv_reltimedwait(). > > It seemed that way to me before the first code reviewer (Madhavan) > pointed out that with cv_reltimedwait() the timer would be reloaded with > the same delta at each iteration - where it had originally specified an > absolute time limit. Er, but one must always be prepared to wait again on a CV on wakeup. So what should happen is that cv_reltimedwait*() should output the amount of time left. Nico -- From Rafael.Vanoni@sun.com Tue Sep 1 16:26:11 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n81NQAja005819 for ; Tue, 1 Sep 2009 16:26:10 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n81NQ3AR016125 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Sep 2009 07:26:09 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPB00H13FRJSL00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Sep 2009 17:26:07 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPB005ISFRJBT70@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Sep 2009 17:26:07 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n81NQ6dI029939 for ; Tue, 01 Sep 2009 16:26:06 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPB00L00FL31O00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Sep 2009 16:26:06 -0700 (PDT) Received: from [129.146.229.172] ([unknown] [129.146.229.172]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPB00KIGFRET0G0@fe-sfbay-10.sun.com>; Tue, 01 Sep 2009 16:26:03 -0700 (PDT) Date: Tue, 01 Sep 2009 16:26:02 -0700 From: Rafael Vanoni Subject: Re: PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009] In-reply-to: <20090901225544.GF965427@eng.sun.com> Sender: Rafael.Vanoni@sun.com To: Edward Pilatowicz Cc: Jerry Gilliam , PSARC-ext@sun.com, Eric Saxe , Madhavan.Venkataraman@sun.com, Steven Sistare Message-id: <4A9DAD8A.5000901@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A9D90A5.8030905@sun.com> <20090901225544.GF965427@eng.sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090804) Status: RO Content-Length: 24693 Hey Ed Yes, I actually experimented with moving the new interface to hrtime_t instead of clock_t, but that involved adding conversion statements to all previous consumers of cv_timedwait(), all of which had been designed with clock_t in mind. If a new interface with such characteristic is necessary or desired, I believe it should be implemented so that folks would gradually migrate their code to it. Not just have someone change the immediate routine that consumes the interface, but do it with a full understanding of how their code handles time. Thanks, Rafael Edward Pilatowicz wrote: > hey rafael, > > for the new cv_* functions the delta is still specified by a clock_t, > which iirc is still subject to the value of "hz". many driver writers > incorrectly assume that "hz" is always 100. hence when some > brave/foolish person comes along and sets "hires_tick" or a custom "hz" > value, things break. getting to my point, if we're introducing new > interfaces to allow driver writers to simplify their drivers, perhaps we > could move away from having them deal with clock_t values all together? > did you consider creating the new interfaces to allow the caller to > simply specify the requested delta directly in > NANOSEC/MICROSEC/MILLISEC/SEC values? > > ed > > On Tue, Sep 01, 2009 at 02:22:45PM -0700, Jerry Gilliam wrote: >> I am sponsoring the following fast-track on behalf of Rafael Vanoni, >> with a time-out of 09/09/2009. The project desires >> minor/major binding, plus micro/patch binding for one >> interface, as specified. >> >> ------------------------------------- >> >> Template Version: @(#)onepager.txt 1.35 07/11/07 SMI >> Copyright 2007 Sun Microsystems >> >> 1. Introduction >> 1.1. Project/Component Working Name: >> Tickless Kernel Architecture / lbolt decoupling >> >> 1.2. Name of Document Author/Supplier: >> Rafael Vanoni Polanczyk (rafael.vanoni@sun.com) >> >> 1.3. Date of This Document: >> 08/04/09 >> >> 1.3.1. Date this project was conceived: >> 07/01/09 >> >> 1.4. Name of Major Document Customer(s)/Consumer(s): >> 1.4.1. The PAC or CPT you expect to review your project: >> Solaris PAC >> 1.4.2. The ARC(s) you expect to review your project: >> 1.4.3. The Director/VP who is "Sponsoring" this project: >> Greg.Lavender@Sun.COM >> 1.4.4. The name of your business unit: >> Systems >> >> 1.5. Email Aliases: >> 1.5.1. Responsible Manager: darrin.johnson@sun.com >> 1.5.2. Responsible Engineer: rafael.vanoni@sun.com >> 1.5.3. Marketing Manger: mike.mulkey@sun.com >> 1.5.4. Interest List: tickless-dev@opensolaris.org >> >> >> 2. Project Summary >> 2.1. Project Description: >> The tickless project aims at implementing the services provided by the >> clock cyclic in an event driven fashion. The first sub-project is the >> decoupling of the lbolt and lbolt64 variables from clock(). These two >> variables are incremented at each firing of the clock cyclic and provide >> a time reference to the system. They are being replaced by two routines >> that are backed by gethrtime(), the existing ddi_get_lbolt() and >> the new ddi_get_lbolt64(), introduced as a migration path for existing >> non-DDI compliant consumers. >> >> This project also presents a solution to minimize the usage of the DDI >> lbolt routines through new interfaces, and a method to prevent any >> performance impact of migrating inexpensive references to variables, to >> calling of routines. These are described in detail on section 4.1. >> >> >> 4. Technical Description: >> 4.1. Details: >> lbolt and lbolt64 variables will be replaced by two routines, >> ddi_get_lbolt() and ddi_get_lbolt64(), which are backed by a hardware >> counter to provide the same service in en event driven way. >> >> One of the major consumers of the lbolt service are the cv_timedwait() >> and cv_timedwait_sig() routines, which require lbolt to form one of its >> arguments (an absolute value of time) and once again internally to >> decompose it into a relative time. This project is introducing two new >> routines, cv_reltimedwait() and cv_reltimedwait_sig() which will perform >> the same service of the previously mentioned routines but simply >> receiving a relative time, and not requiring lbolt at all. These new >> routines will also have a new argument of type time_res_t to inform >> the underlying timeout system as to how accurately the given timeout >> must expire. This will allow the kernel to anticipate or defer such >> timeouts when possible, allowing the system to stay idle for longer >> periods of time. >> >> Some consumers of the lbolt and lbolt64 variables may have inexplicit >> dependencies on the cheapness of reading a memory position that will be >> exposed when migrated to a gethrtime() backed routine. In such cases >> migrating references to lbolt and lbolt64 to ddi_get_lbolt() and >> ddi_get_lbolt64() will have a negative performance impact. To address >> this case, our project will perform the lbolt service in an hybrid way, >> switching from event to cyclic driven when the DDI lbolt routines are >> being heavily used. This cyclic mode will reprogram a timer that will >> expire at each clock tick and increment an internal (lbolt like) >> variable and return its value to the consumer. This cyclic will only >> be activated during periods of heavy load, and will switch itself off >> when the activity subsides. >> >> The decision to remove the lbolt and lbolt64 variables was made during >> design review, and a consensus was reached on the basis that, since >> we're reaching the end of a major release, this is the right moment to >> obsolete these. The side effects and cost of maintaining such symbols >> outweigh the benefits. However, this decision can be re-evaluated in >> case the negative impact on 3rd party modules during the development >> release is greater than expected. We're working with ISV and RPE to >> minimize the impact pro-actively. >> >> 4.2. Bug/RFE Number(s): >> 6860030 tickless clock requires a clock() decoupled lbolt / lbolt64 >> >> 4.5. Interfaces: >> This project is adding the following interfaces to the DDI: >> >> int64_t ddi_get_lbolt64(void); >> >> clock_t cv_reltimedwait(kcondvar_t *cvp, kmutex_t *mp, clock_t delta, >> time_res_t res); >> >> clock_t cv_reltimedwait_sig(kcondvar_t *cvp, kmutex_t *mp, clock_t >> delta, time_res_t res); >> >> With time_res_t defined as >> >> enum time_res { >> TR_NANOSEC, >> TR_MICROSEC, >> TR_MILLISEC, >> TR_SEC, >> TR_CLOCK_TICK, >> TR_COUNT >> }; >> >> typedef enum time_res time_res_t; >> >> In addition to that, the lbolt and lbolt64 variables (which are >> *private* symbols known to be used by non-DDI compliant modules) are >> being removed. 3rd party modules that are not brought up to speed will >> fail to load. >> >> In summary: >> >> Interface Commitment Comments >> ----------------------------------------------------------------------- >> ddi_get_lbolt64() Public/DDI return lbolt64 >> cv_reltimedwait(9F) Public/DDI cv_timedwait(9f), relative time >> cv_reltimedwait_sig(9F) Public/DDI cv_timedwait_sig(9F), relative time >> lbolt Obsolete commonly referenced kernel symbol >> lbolt64 Obsolete commonly referenced kernel symbol >> >> We also plan on back porting the ddi_get_lbolt64() interface to Solaris >> 10 Update 9 to extend the migration path for S10 users who would like >> to update their modules before moving to Solaris Nevada or the next >> version of Solaris. These users already have ddi_get_lbolt() but >> currently lack the 64 bits version of it. Such back port will have >> patch release binding. >> >> >> 4.6. Doc Impact: >> 6868417 updates for tickless kernel/lbolt decoupling (6860030) >> >> Updates to the 'Writing Device Drivers' document are necessary, the >> project team is in contact with the documentation group to address >> these. >> >> >> 5. Reference Documents: >> This project is being developed through OpenSolaris, our project pages >> and alias contain all the necessary information: >> http://opensolaris.org/os/project/tickless/ >> http://opensolaris.org/os/project/tickless/tasks/lbolt/ >> tickless-dev@opensolaris.org >> >> >> 6. Resources and Schedule: >> 6.5. ARC review type: Fast track >> 6.6. ARC Exposure: open >> >> >> >> >> >> Updates to existing man pages: >> ------------------------------ >> >> drv_getparm.9f >> >> PARAMETERS >> ... >> >> LBOLT Read the value of lbolt. lbolt is a clock_t that | >> represents the number of clock ticks since system | >> boot. No special treatment is applied when | >> this value overflows the maximum value of the >> signed integral type clock_t. When this occurs, >> its value will be negative, and its magnitude will >> be decreasing until it again passes zero. It can >> ... >> >> >> >> >> drv_hztousec.9f >> >> DESCRIPTION >> The drv_hztousec() function converts into microseconds the >> time expressed by hertz, which is in system clock ticks. >> >> The length of time the system has been up since boot can be | >> retrieved by calling ddi_get_lbolt(9F), which will return a | >> value of type clock_t containing the number of clock ticks >> since boot. Drivers often use this value before and after an >> I/O request to measure the amount of time it took the device to >> process the request. The drv_hztousec() function can be used >> by the driver to convert the reading from clock ticks to a >> known unit of time. >> >> >> >> >> Intro.9f >> >> Kernel Functions for Drivers Intro(9F) >> >> ddi_get_instance Solaris DDI >> ddi_get_kt_did Solaris DDI >> ddi_get_lbolt Solaris DDI >> ddi_get_lbolt64 Solaris DDI + >> ddi_get_name Solaris DDI >> ... >> >> >> >> >> Updated ddi_get_lbolt.9f: >> ------------------------- >> >> Kernel Functions for Drivers ddi_get_lbolt(9F) >> >> NAME >> ddi_get_lbolt - returns the number of clock ticks since boot | >> >> SYNOPSIS >> #include >> #include >> #include >> >> clock_t ddi_get_lbolt(void); >> >> INTERFACE LEVEL >> Solaris DDI specific (Solaris DDI). >> >> DESCRIPTION >> ddi_get_lbolt() returns a value that represents the number | >> of clock ticks since the system booted. This value is | >> used as a counter or timer inside the system kernel. >> The tick frequency can be determined by using drv_usectohz(9F) >> which converts microseconds into clock ticks. >> >> >> RETURN VALUES >> ddi_get_lbolt() returns the number of clock ticks since boot | >> in clock_t type. >> >> CONTEXT >> This routine can be called from any context. >> >> SEE ALSO >> ddi_get_lbolt64(9F), ddi_get_time(9F), drv_getparm(9F), >> drv_usectohz(9F) >> >> >> >> >> New man page for ddi_get_lbolt64(): >> ----------------------------------- >> >> Kernel Functions for Drivers ddi_get_lbolt64(9F) >> >> NAME >> ddi_get_lbolt64 - returns the number of clock ticks since boot >> in int64_t type >> >> SYNOPSIS >> #include >> #include >> #include >> >> int64_t ddi_get_lbolt64(void); >> >> INTERFACE LEVEL >> Solaris DDI specific (Solaris DDI). >> >> DESCRIPTION >> ddi_get_lbolt64() returns a value that represents the number >> of clock ticks since the system booted. This value is >> used as a counter or timer inside the system kernel. It is >> essentially the same value returned by ddi_get_lbolt(9F), but in a >> longer data type that will not wrap for 2.9 billion years. >> >> RETURN VALUES >> ddi_get_lbolt64() returns the number of clock ticks since boot >> in int64_t type. >> >> CONTEXT >> This routine can be called from any context. >> >> SEE ALSO >> ddi_get_lbolt(9F), ddi_get_time(9F) >> >> Writing Device Drivers >> >> STREAMS Programming Guide >> >> SunOS 5.11 Last change: 29 Jul 2009 1 >> >> >> Updates to condvar(9f): >> ---------------------- >> >> Kernel Functions for Drivers condvar(9F) >> >> NAME >> condvar, cv_init, cv_destroy, cv_wait, cv_signal, >> cv_broadcast, cv_wait_sig, cv_timedwait, cv_timedwait_sig, >> cv_reltimedwait, cv_reltimedwait_sig - condition variable >> routines >> >> SYNOPSIS >> #include >> >> void cv_init(kcondvar_t *cvp, char *name, kcv_type_t type, void *arg); >> >> void cv_destroy(kcondvar_t *cvp); >> >> void cv_wait(kcondvar_t *cvp, kmutex_t *mp); >> >> void cv_signal(kcondvar_t *cvp); >> >> void cv_broadcast(kcondvar_t *cvp); >> >> int cv_wait_sig(kcondvar_t *cvp, kmutex_t *mp); >> >> clock_t cv_timedwait(kcondvar_t *cvp, kmutex_t *mp, clock_t timeout); >> >> clock_t cv_timedwait_sig(kcondvar_t *cvp, kmutex_t *mp, clock_t timeout); >> >> | clock_t cv_reltimedwait(kcondvar_t *cvp, kmutex_t *mp, clock_t delta, >> | time_res_t resolution); >> >> | clock_t cv_reltimedwait_sig(kcondvar_t *cvp, kmutex_t *mp, clock_t delta, >> | time_res_t resolution); >> >> INTERFACE LEVEL >> Solaris DDI specific (Solaris DDI). >> >> PARAMETERS >> cvp A pointer to an abstract data type kcondvar_t. >> >> mp A pointer to a mutual exclusion lock (kmutex_t), >> initialized by mutex_init(9F) and held by the >> caller. >> >> name Descriptive string. This is obsolete and should >> be NULL. (Non-NULL strings are legal, but they're >> a waste of kernel memory.) >> >> SunOS 5.11 Last change: 02 Aug 2009 1 >> >> Kernel Functions for Drivers condvar(9F) >> >> type The constant CV_DRIVER. >> >> arg A type-specific argument, drivers should pass arg >> as NULL. >> >> timeout A time, in absolute ticks since boot, when >> cv_timedwait() or cv_timedwait_sig() should >> return. >> >> | delta A time, in relative ticks, when cv_reltimedwait() >> | or cv_reltimedwait_sig() should return. >> | >> | resolution A flag that specifies how accurately the relative >> | time interval should be. Possible values are >> | TR_NANOSEC, TR_MICROSEC, TR_MILLISEC, TR_SEC or >> | TR_CLOCK_TICK, the former indicating that the interval >> | should be aligned to system clock ticks. This >> | information allows the system to anticipate or >> | deffer the timeout expiration in order to batch process >> | similarly expiring events. Allowing the system to >> | stay idle for longer periods of time and enhance >> | its power efficiency. >> >> >> DESCRIPTION >> Condition variables are a standard form of thread synchroni- >> zation. They are designed to be used with mutual exclusion >> locks (mutexes). The associated mutex is used to ensure that >> a condition can be checked atomically and that the thread >> can block on the associated condition variable without miss- >> ing either a change to the condition or a signal that the >> condition has changed. Condition variables must be initial- >> ized by calling cv_init(), and must be deallocated by cal- >> ling cv_destroy(). >> >> The usual use of condition variables is to check a condition >> (for example, device state, data structure reference count, >> etc.) while holding a mutex which keeps other threads from >> changing the condition. If the condition is such that the >> thread should block, cv_wait() is called with a related con- >> dition variable and the mutex. At some later point in time, >> another thread would acquire the mutex, set the condition >> such that the previous thread can be unblocked, unblock the >> previous thread with cv_signal() or cv_broadcast(), and then >> release the mutex. >> >> cv_wait() suspends the calling thread and exits the mutex >> atomically so that another thread which holds the mutex can- >> not signal on the condition variable until the blocking >> thread is blocked. Before returning, the mutex is reac- >> quired. >> >> cv_signal() signals the condition and wakes one blocked >> thread. All blocked threads can be unblocked by calling >> cv_broadcast(). cv_signal() and cv_broadcast() can be called >> by a thread even if it does not hold the mutex passed into >> cv_wait(), though holding the mutex is necessary to ensure >> predictable scheduling. >> >> SunOS 5.11 Last change: 02 Aug 2009 2 >> >> Kernel Functions for Drivers condvar(9F) >> >> The function cv_wait_sig() is similar to cv_wait() but >> returns 0 if a signal (for example, by kill(2)) is sent to >> the thread. In any case, the mutex is reacquired before >> returning. >> >> The function cv_timedwait() is similar to cv_wait(), except >> that it returns -1 without the condition being signaled >> after the timeout time has been reached. >> >> The function cv_timedwait_sig() is similar to cv_timedwait() >> and cv_wait_sig(), except that it returns -1 without the >> condition being signaled after the timeout time has been >> reached, or 0 if a signal (for example, by kill(2)) is sent >> to the thread. >> >> For both cv_timedwait() and cv_timedwait_sig(), time is in >> absolute clock ticks since the last system reboot. The >> current time may be found by calling ddi_get_lbolt(9F). >> >> | The cv_reltimedwait() function is similar to cv_timedwait(), >> | except that it takes a relative time value as argument and >> | it also takes an additional argument to specify the accuracy >> | of such interval. cv_reltimedwait_sig() is analogous to >> | cv_timedwait_sig(), but takes the same arguments as >> | cv_reltimedwait(). >> >> RETURN VALUES >> 0 For cv_wait_sig(), cv_timedwait_sig() and cv_reltimedwait_sig() >> indicates >> that the condition was not necessarily signaled and >> the function returned because a signal (as in >> kill(2)) was pending. >> >> | -1 For cv_timedwait(), cv_timedwait_sig(), >> | cv_reltimedwait() and cv_reltimedwait_sig() indicates >> that the condition was not necessarily signaled and >> the function returned because the timeout time was >> reached. >> >> | >0 For cv_wait_sig(), cv_timedwait(), cv_timedwait_sig(), >> | cv_reltimedwait() or cv_reltimedwait_sig() >> | indicates that the condition was >> met and the function returned due to a call to >> cv_signal() or cv_broadcast(), or due to a prema- >> ture wakeup (see NOTES). >> >> CONTEXT >> These functions can be called from user, kernel or interrupt >> context. In most cases, however, cv_wait(), cv_timedwait(), >> | cv_wait_sig(), cv_timedwait_sig(), cv_reltimedwait() and >> | cv_reltimedwait_sig() >> should not be called >> from interrupt context, and cannot be called from a high- >> level interrupt context. >> >> If cv_wait(), cv_timedwait(), cv_wait_sig(), >> | cv_timedwait_sig(), cv_reltimedwait() or cv_reltimedwait_sig() >> | are used from interrupt context, lower- >> >> SunOS 5.11 Last change: 02 Aug 2009 3 >> >> Kernel Functions for Drivers condvar(9F) >> >> priority interrupts will not be serviced during the wait. >> This means that if the thread that will eventually perform >> the wakeup becomes blocked on anything that requires the >> lower-priority interrupt, the system will hang. >> >> For example, the thread that will perform the wakeup may >> need to first allocate memory. This memory allocation may >> require waiting for paging I/O to complete, which may >> require a lower-priority disk or network interrupt to be >> serviced. In general, situations like this are hard to >> predict, so it is advisable to avoid waiting on condition >> variables or semaphores in an interrupt context. >> >> EXAMPLES >> Example 1 Waiting for a Flag Value in a Driver's Unit >> >> Here the condition being waited for is a flag value in a >> driver's unit structure. The condition variable is also in >> the unit structure, and the flag word is protected by a >> mutex in the unit structure. >> >> mutex_enter(&un->un_lock); >> while (un->un_flag & UNIT_BUSY) >> cv_wait(&un->un_cv, &un->un_lock); >> un->un_flag |= UNIT_BUSY; >> mutex_exit(&un->un_lock); >> >> Example 2 Unblocking Threads Blocked by the Code in Example >> 1 >> >> At some later point in time, another thread would execute >> the following to unblock any threads blocked by the above >> code. >> >> mutex_enter(&un->un_lock); >> un->un_flag &= ~UNIT_BUSY; >> cv_broadcast(&un->un_cv); >> mutex_exit(&un->un_lock); >> >> NOTES >> | It is possible for cv_wait(), cv_wait_sig(), cv_timedwait(), >> | cv_timedwait_sig(), cv_reltimedwait() and cv_reltimedwait_sig() >> | to return prematurely, that is, not >> due to a call to cv_signal() or cv_broadcast(). This occurs >> most commonly in the case of cv_wait_sig(), >> >> SunOS 5.11 Last change: 02 Aug 2009 4 >> >> Kernel Functions for Drivers condvar(9F) >> >> | cv_timedwait_sig() and cv_reltimedwait_sig() when the thread >> | is stopped and restarted >> by job control signals or by a debugger, but can happen in >> other cases as well, even for cv_wait(). Code that calls >> these functions must always recheck the reason for blocking >> and call again if the reason for blocking is still true. >> >> | If your driver needs to wait on behalf of processes that >> | have real-time constraints, use cv_timedwait() or cv_reltimedwait() >> | rather than >> delay(9F). The delay() function calls timeout(9F), which can >> be subject to priority inversions. >> >> Not all threads can receive signals from user level >> processes. In cases where such reception is impossible (such >> as during execution of close(9E) due to exit(2)), >> cv_wait_sig() behaves as cv_wait(), cv_timedwait_sig() >> | behaves as cv_timedwait() and cv_reltimedwait_sig() behaves as >> | cv_reltimedwait(). >> To avoid unkillable processes, >> users of these functions may need to protect against waiting >> indefinitely for events that might not occur. The >> ddi_can_receive_sig(9F) function is provided to detect when >> signal reception is possible. >> >> SEE ALSO >> kill(2), ddi_can_receive_sig(9F), ddi_get_lbolt(9F), >> | ddi_get_lbolt64(9F), mutex(9F), mutex_init(9F) >> >> Writing Device Drivers >> >> SunOS 5.11 Last change: 02 Aug 2009 5 From gdamore@sun.com Tue Sep 1 20:51:00 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n823p0W9019236 for ; Tue, 1 Sep 2009 20:51:00 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n823ofNa022616 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 1 Sep 2009 21:50:59 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPB00001S0WBZ00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Sep 2009 20:50:56 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPB00M46S0WSM10@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Sep 2009 20:50:56 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n823ouj2009311 for ; Tue, 01 Sep 2009 20:50:56 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPB00800RTCEK00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 01 Sep 2009 20:50:56 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPB0066FS0UHU10@fe-sfbay-10.sun.com>; Tue, 01 Sep 2009 20:50:56 -0700 (PDT) Date: Tue, 01 Sep 2009 20:50:54 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009] In-reply-to: <20090901232153.GD1033@Sun.COM> Sender: Garrett.Damore@sun.com To: Nicolas Williams Cc: Rafael Vanoni , Jerry Gilliam , PSARC-ext@sun.com, Eric Saxe , Madhavan.Venkataraman@sun.com, Steven Sistare Message-id: <4A9DEB9E.2090302@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A9D90A5.8030905@sun.com> <4A9D94BD.8040000@sun.com> <4A9D9657.9010104@sun.com> <4A9D9F59.50600@sun.com> <4A9DA1A7.2060308@sun.com> <20090901225020.GA1033@Sun.COM> <4A9DAA7E.9030008@sun.com> <20090901232153.GD1033@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1704 Nicolas Williams wrote: > On Tue, Sep 01, 2009 at 04:13:02PM -0700, Rafael Vanoni wrote: > >> Nicolas Williams wrote: >> >>> Looks like a candidate for cv_reltimedwait(). >>> >> It seemed that way to me before the first code reviewer (Madhavan) >> pointed out that with cv_reltimedwait() the timer would be reloaded with >> the same delta at each iteration - where it had originally specified an >> absolute time limit. >> > > Er, but one must always be prepared to wait again on a CV on wakeup. I'm not sure, is this always true? I think threads don't wake up typically unless signaled or timed out. But if the CV is used for more than one thing, then yes, you need to check again. You also need to check the condition anyway, because you have to assume the lock was dropped. But that's not quite the same thing is it? I mean, cv_wait(9F) makes no claims that a thread will wake *other* the situation where cv_signal or cv_broadcast was used on the cv. Likewise, the only way that I can see that cv_timedwait() returns is either if the cv was signaled, or the timeout expired. (And which case is reflected in the return value.) > So > what should happen is that cv_reltimedwait*() should output the amount > of time left. > This would be nice. However, drivers can work around this by calling ddi_get_lbolt64() (or gethrtime() or whatever other method is needed) to look at the time before and after the call. Generally, if you can express a relative timeout, and if you can get the current time, then you don't need a direct absolute interface. Which goes to my original suggestion to Obsolete the legacy relative calls. - Garrett > Nico > From Nicolas.Williams@sun.com Tue Sep 1 21:41:11 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n824fBkP019883 for ; Tue, 1 Sep 2009 21:41:11 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n824f9WA001709; Tue, 1 Sep 2009 21:41:09 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPB00601UCLZ600@brm-avmta-1.central.sun.com>; Tue, 01 Sep 2009 22:41:09 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPB00EJEUCKSK70@brm-avmta-1.central.sun.com>; Tue, 01 Sep 2009 22:41:08 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n824bhOL008940; Tue, 01 Sep 2009 23:37:43 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n824bhUd008939; Tue, 01 Sep 2009 23:37:43 -0500 (CDT) Date: Tue, 01 Sep 2009 23:37:43 -0500 From: Nicolas Williams Subject: Re: PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009] In-reply-to: <4A9DEB9E.2090302@sun.com> To: "Garrett D'Amore" Cc: Rafael Vanoni , Jerry Gilliam , PSARC-ext@sun.com, Eric Saxe , Madhavan.Venkataraman@sun.com, Steven Sistare Message-id: <20090902043743.GH1033@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4A9D90A5.8030905@sun.com> <4A9D94BD.8040000@sun.com> <4A9D9657.9010104@sun.com> <4A9D9F59.50600@sun.com> <4A9DA1A7.2060308@sun.com> <20090901225020.GA1033@Sun.COM> <4A9DAA7E.9030008@sun.com> <20090901232153.GD1033@Sun.COM> <4A9DEB9E.2090302@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1650 On Tue, Sep 01, 2009 at 08:50:54PM -0700, Garrett D'Amore wrote: > Nicolas Williams wrote: > >Er, but one must always be prepared to wait again on a CV on wakeup. > > I'm not sure, is this always true? I think threads don't wake up > typically unless signaled or timed out. But if the CV is used for more > than one thing, then yes, you need to check again. You also need to > check the condition anyway, because you have to assume the lock was > dropped. But that's not quite the same thing is it? ... I was referring to the need to check the condition. Which is why the code I quoted has a loop around cv_timedwait(). Clearly one need not do that on _error_ or _timeout_, only on success. > > So > >what should happen is that cv_reltimedwait*() should output the amount > >of time left. > > This would be nice. ... But that's what the manpage says! (Including the one updated by this case, as updated, as well as before.) Which means, IMO, that the mentioned drivers can get by with cv_reltimedwait*(). So the loop I quoted should be changed to: /* wait loading run_text until completed or timeout */ clk = drv_usectohz(1000000); while (!(sc->sc_flags & IWH_F_PUT_SEG)) { if ((clk = cv_reltimedwait(&sc->sc_put_seg_cv, &sc->sc_glock, clk)) < 0) { break; } } > Which goes to my original suggestion to Obsolete the legacy relative > calls. It depends though. Is there something special about the wall clock timedwait functions w.r.t. suspend and real-time semantics? I imagine the answer is "no", in which case I think you're right, the absolute timed wait functions should be obsoleted, period. Nico -- From casper@Holland.Sun.COM Wed Sep 2 00:32:55 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n827WtnE001818 for ; Wed, 2 Sep 2009 00:32:55 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n827Wnwj001735 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Wed, 2 Sep 2009 08:32:54 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPC00E0H2ATJ300@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 02 Sep 2009 00:32:53 -0700 (PDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPC00I9G2AR20B0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 02 Sep 2009 00:32:52 -0700 (PDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n827WkU8020357; Wed, 02 Sep 2009 08:32:46 +0100 (BST) Date: Wed, 02 Sep 2009 09:32:42 +0200 From: Casper.Dik@sun.com Subject: Re: PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009] In-reply-to: <4A9D90A5.8030905@sun.com> Sender: casper@Holland.Sun.COM To: Jerry Gilliam Cc: PSARC-ext@sun.com, Rafael Vanoni , Eric Saxe , Madhavan.Venkataraman@sun.com, Steven Sistare Message-id: <200909020732.n827WkU8020357@dm-holland-02.uk.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A9D90A5.8030905@sun.com> Status: RO Content-Length: 1370 > One of the major consumers of the lbolt service are the cv_timedwait() > and cv_timedwait_sig() routines, which require lbolt to form one of its > arguments (an absolute value of time) and once again internally to > decompose it into a relative time. This project is introducing two new > routines, cv_reltimedwait() and cv_reltimedwait_sig() which will perform > the same service of the previously mentioned routines but simply > receiving a relative time, and not requiring lbolt at all. These new > routines will also have a new argument of type time_res_t to inform > the underlying timeout system as to how accurately the given timeout > must expire. This will allow the kernel to anticipate or defer such > timeouts when possible, allowing the system to stay idle for longer > periods of time. In the Solaris kernel at this time, each user visible timeout (poll, timers) need to wait for at least 2 clock ticks as the kernel doesn't know when the last tick occurred. Will this new implementation allow for shorter timeouts and more precise timeouts? The minimum time waited should be around one "clock tick" and not a lot less; some applications expect that the kernel will wait for exactly one clock tick, even though they ask the kernel to wait for 1 microsecond. Casper From casper@holland.sun.com Wed Sep 2 00:43:52 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n827hpfj001971 for ; Wed, 2 Sep 2009 00:43:51 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n827hlhD007759; Wed, 2 Sep 2009 08:43:49 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPC00H072SZ5400@nwk-avmta-2.sfbay.sun.com>; Wed, 02 Sep 2009 00:43:47 -0700 (PDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPC00GNH2SYYS00@nwk-avmta-2.sfbay.sun.com>; Wed, 02 Sep 2009 00:43:47 -0700 (PDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n827hefL023517; Wed, 02 Sep 2009 08:43:40 +0100 (BST) Date: Wed, 02 Sep 2009 09:43:40 +0200 From: Casper.Dik@sun.com Subject: Re: PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009] In-reply-to: <4A9DA0C9.1020502@sun.com> Sender: casper@holland.sun.com To: "Garrett D'Amore" Cc: Joerg Schilling , Rafael.Vanoni@sun.com, PSARC-ext@sun.com, Jerry.Gilliam@sun.com, Steve.Sistare@sun.com, Madhavan.Venkataraman@sun.com, Eric.Saxe@sun.com Message-id: <200909020743.n827hefL023517@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A9D90A5.8030905@sun.com> <4a9d9927./ZRbLvLmxk+UnZdT%Joerg.Schilling@fokus.fraunhofer.de> <4A9DA0C9.1020502@sun.com> Status: RO Content-Length: 982 >Actually, I could really use the ability to use a timer based service >that had a smaller window than 10 msec. For example, many audio devices >have crummy interrupt capabilities... its a lot nicer (smoother audio) >if I have a reliable way to get a periodic running at smaller >intervals. (5 to 10 msec, but with precision -- the current stuff is >simply too coarse.) > >This would simplify a lot of audio device drivers. And make them more >robust as well. :-) Do they work better if you set "hz" to 1000? (hires_tick)? I remember that some devices failed to work when you set hz to 1000 such as the audio in the Ultra 45 (since fixed) but this was because of bad code. If your driver wants to sleep a short amount of time AND that time is less then 10ms, that code is hardly ever tested. (We should vet all the uses of drv_usectohz() and more sure that the argument is at least 10000 or that we have an actual reason that we might want to sleep less) Casper From Steve.Sistare@sun.com Wed Sep 2 05:31:48 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n82CVl9l014263 for ; Wed, 2 Sep 2009 05:31:48 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n82CViEL003629 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Sep 2009 20:31:46 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPC00A0DG4YI000@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 02 Sep 2009 06:31:46 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPC005TKG4XVH30@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 02 Sep 2009 06:31:45 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n82CVjgd001130 for ; Wed, 02 Sep 2009 12:31:45 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPC00F00FXVRB00@mail-amer.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 02 Sep 2009 06:31:45 -0600 (MDT) Received: from [129.148.180.120] ([unknown] [129.148.180.120]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPC007O0G4DRUC0@mail-amer.sun.com>; Wed, 02 Sep 2009 06:31:28 -0600 (MDT) Date: Wed, 02 Sep 2009 08:30:26 -0400 From: Steve Sistare Subject: Re: PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009] In-reply-to: <200909020732.n827WkU8020357@dm-holland-02.uk.sun.com> Sender: Steve.Sistare@sun.com To: Casper.Dik@sun.com Cc: Jerry Gilliam , PSARC-ext@sun.com, Rafael Vanoni , Eric Saxe , Madhavan.Venkataraman@sun.com Message-id: <4A9E6562.7060801@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A9D90A5.8030905@sun.com> <200909020732.n827WkU8020357@dm-holland-02.uk.sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090311) Status: RO Content-Length: 1684 On 09/02/09 03:32, Casper.Dik@Sun.COM wrote: >> One of the major consumers of the lbolt service are the cv_timedwait() >> and cv_timedwait_sig() routines, which require lbolt to form one of its >> arguments (an absolute value of time) and once again internally to >> decompose it into a relative time. This project is introducing two new >> routines, cv_reltimedwait() and cv_reltimedwait_sig() which will perform >> the same service of the previously mentioned routines but simply >> receiving a relative time, and not requiring lbolt at all. These new >> routines will also have a new argument of type time_res_t to inform >> the underlying timeout system as to how accurately the given timeout >> must expire. This will allow the kernel to anticipate or defer such >> timeouts when possible, allowing the system to stay idle for longer >> periods of time. > > In the Solaris kernel at this time, each user visible timeout (poll, > timers) need to wait for at least 2 clock ticks as the kernel doesn't > know when the last tick occurred. > > Will this new implementation allow for shorter timeouts and more > precise timeouts? The new callout implementation (CR 6565503 and others thru 6789031) fixes these problems. poll(10 msec) returns in 10 msec. The minimum timeout is still one tick, so to get shorter timeouts, you must set hires_tick. - Steve > > The minimum time waited should be around one "clock tick" and > not a lot less; some applications expect that the kernel will > wait for exactly one clock tick, even though they ask the kernel > to wait for 1 microsecond. > > Casper From casper@holland.sun.com Wed Sep 2 05:36:36 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n82Caa9e014300 for ; Wed, 2 Sep 2009 05:36:36 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n82CaaR4014295 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Wed, 2 Sep 2009 05:36:36 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPC00801GD09600@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 02 Sep 2009 05:36:36 -0700 (PDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPC003IWGCZYX30@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 02 Sep 2009 05:36:36 -0700 (PDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n82CaTTd047884; Wed, 02 Sep 2009 13:36:29 +0100 (BST) Date: Wed, 02 Sep 2009 14:36:29 +0200 From: Casper.Dik@sun.com Subject: Re: PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009] In-reply-to: <4A9E6562.7060801@sun.com> Sender: casper@holland.sun.com To: Steve Sistare Cc: Jerry Gilliam , PSARC-ext@sun.com, Rafael Vanoni , Eric Saxe , Madhavan.Venkataraman@sun.com Message-id: <200909021236.n82CaTTd047884@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A9D90A5.8030905@sun.com> <200909020732.n827WkU8020357@dm-holland-02.uk.sun.com> <4A9E6562.7060801@sun.com> Status: RO Content-Length: 329 >The new callout implementation (CR 6565503 and others thru 6789031) >fixes these problems. poll(10 msec) returns in 10 msec. The minimum >timeout is still one tick, so to get shorter timeouts, you must set >hires_tick. Just to be really sure: poll(10ms) now returns in 10ms and NOT in the interval [10ms .. 20ms)? Casper From Steve.Sistare@sun.com Wed Sep 2 05:47:07 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n82Cl7R9014388 for ; Wed, 2 Sep 2009 05:47:07 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n82Cl2eX016860 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Sep 2009 05:47:07 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPC00E01GUIGD00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 02 Sep 2009 05:47:06 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPC00KF3GUIVEE0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 02 Sep 2009 05:47:06 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n82Cl6MV008951 for ; Wed, 02 Sep 2009 12:47:06 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPC00C00GOE1200@mail-amer.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 02 Sep 2009 06:47:06 -0600 (MDT) Received: from [129.148.180.120] ([unknown] [129.148.180.120]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPC003RSGUFGM00@mail-amer.sun.com>; Wed, 02 Sep 2009 06:47:06 -0600 (MDT) Date: Wed, 02 Sep 2009 08:46:03 -0400 From: Steve Sistare Subject: Re: PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009] In-reply-to: <200909021236.n82CaTTd047884@dm-holland-02.uk.sun.com> Sender: Steve.Sistare@sun.com To: Casper.Dik@sun.com Cc: Jerry Gilliam , PSARC-ext@sun.com, Rafael Vanoni , Eric Saxe , Madhavan.Venkataraman@sun.com Message-id: <4A9E690B.6090207@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A9D90A5.8030905@sun.com> <200909020732.n827WkU8020357@dm-holland-02.uk.sun.com> <4A9E6562.7060801@sun.com> <200909021236.n82CaTTd047884@dm-holland-02.uk.sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090311) Status: RO Content-Length: 413 On 09/02/09 08:36, Casper.Dik@Sun.COM wrote: > >> The new callout implementation (CR 6565503 and others thru 6789031) >> fixes these problems. poll(10 msec) returns in 10 msec. The minimum >> timeout is still one tick, so to get shorter timeouts, you must set >> hires_tick. > > Just to be really sure: poll(10ms) now returns in 10ms and NOT in the > interval [10ms .. 20ms)? > > Casper > Correct - steve From darren.moffat@sun.com Wed Sep 2 05:59:06 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n82Cx6si014805 for ; Wed, 2 Sep 2009 05:59:06 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n82Cx4T2022099 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Sep 2009 05:59:06 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPC00B15HEH1400@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 05:59:05 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPC003CCHEGYM60@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 05:59:05 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n82Cx3Ak014217 for ; Wed, 02 Sep 2009 12:59:04 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPC00I00H9AFW00@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 13:58:55 +0100 (BST) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPC00JOAHDY30E0@fe-emea-10.sun.com>; Wed, 02 Sep 2009 13:58:46 +0100 (BST) Date: Wed, 02 Sep 2009 13:58:45 +0100 From: Darren J Moffat Subject: Re: PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009] In-reply-to: <4A9E690B.6090207@sun.com> Sender: darren.moffat@sun.com To: Steve Sistare Cc: Jerry Gilliam , PSARC-ext@sun.com, Rafael Vanoni , Eric Saxe , Madhavan.Venkataraman@sun.com Message-id: <4A9E6C05.10800@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A9D90A5.8030905@sun.com> <200909020732.n827WkU8020357@dm-holland-02.uk.sun.com> <4A9E6562.7060801@sun.com> <200909021236.n82CaTTd047884@dm-holland-02.uk.sun.com> <4A9E690B.6090207@sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090804) Status: RO Content-Length: 553 Is it safe to assume that this case will update all of the ON and other Solaris consolidations that have code that uses lbolt/lbolt64 ? In the ZFS kernel module alone there are over 30 references to lbolt/lblot64. Was any consideration given to providing something like this: #define lbolt ddi_get_lbolt() #define lbolt64 ddi_get_lbolt64() The main reason for suggesting is based on a quick glance of where ZFS uses lbolt and lbolt64 today those new function calls are going to cause some ugly cstyle issues in a few places. -- Darren J Moffat From Milan.Jurik@sun.com Wed Sep 2 06:26:31 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n82DQVds015020 for ; Wed, 2 Sep 2009 06:26:31 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n82DQU0O029306 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Sep 2009 07:26:31 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPC00G03IO6T300@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 06:26:30 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPC00EZKIO5SS20@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 06:26:30 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n82DQTOk019180 for ; Wed, 02 Sep 2009 13:26:29 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPC00K00IAFDG00@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 14:26:25 +0100 (BST) Received: from [129.157.19.29] ([unknown] [129.157.19.29]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPC0069KIO1A8D0@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 14:26:25 +0100 (BST) Date: Wed, 02 Sep 2009 15:26:23 +0200 From: Milan Jurik Subject: Re: PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009] In-reply-to: <4A9E6C05.10800@Sun.COM> Sender: Milan.Jurik@sun.com To: Darren J Moffat Cc: PSARC-ext Message-id: <1251897983.1943.88.camel@localhost> Organization: Sun Microsystems Czech MIME-version: 1.0 X-Mailer: Evolution 2.26.3 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <4A9D90A5.8030905@sun.com> <200909020732.n827WkU8020357@dm-holland-02.uk.sun.com> <4A9E6562.7060801@sun.com> <200909021236.n82CaTTd047884@dm-holland-02.uk.sun.com> <4A9E690B.6090207@sun.com> <4A9E6C05.10800@Sun.COM> Status: RO Content-Length: 845 Hi, Darren J Moffat píše v st 02. 09. 2009 v 13:58 +0100: > Is it safe to assume that this case will update all of the ON and other > Solaris consolidations that have code that uses lbolt/lbolt64 ? > > In the ZFS kernel module alone there are over 30 references to > lbolt/lblot64. > > Was any consideration given to providing something like this: > > #define lbolt ddi_get_lbolt() > #define lbolt64 ddi_get_lbolt64() > > The main reason for suggesting is based on a quick glance of where ZFS > uses lbolt and lbolt64 today those new function calls are going to cause > some ugly cstyle issues in a few places. > Is it good idea to use macro just to make C-style test happy? Isn't it better to not use such "macro hack", make the code "ugly" and fill new CR per case asking to do source code refactorization? Best regards, Milan From gdamore@Sun.COM Wed Sep 2 07:19:23 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n82EJMDL015631 for ; Wed, 2 Sep 2009 07:19:23 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n82EJMQV000075 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Sep 2009 08:19:22 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPC00L05L495F00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 02 Sep 2009 08:19:21 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPC0056LL48VQF0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 02 Sep 2009 08:19:21 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n82EJK8R029211 for ; Wed, 02 Sep 2009 07:19:20 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPC00900L3FT400@fe-sfbay-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 02 Sep 2009 07:19:20 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPC00GKKL47Q450@fe-sfbay-10.sun.com>; Wed, 02 Sep 2009 07:19:20 -0700 (PDT) Date: Wed, 02 Sep 2009 07:19:19 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009] In-reply-to: <200909020743.n827hefL023517@dm-holland-02.uk.sun.com> Sender: Garrett.Damore@Sun.COM To: Casper.Dik@Sun.COM Cc: Joerg Schilling , Rafael.Vanoni@Sun.COM, PSARC-ext@Sun.COM, jerry.gilliam@Sun.COM, Steve.Sistare@Sun.COM, Madhavan.Venkataraman@Sun.COM, Eric.Saxe@Sun.COM Message-id: <4A9E7EE7.5010505@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A9D90A5.8030905@sun.com> <4a9d9927./ZRbLvLmxk+UnZdT%Joerg.Schilling@fokus.fraunhofer.de> <4A9DA0C9.1020502@sun.com> <200909020743.n827hefL023517@dm-holland-02.uk.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1630 Casper.Dik@Sun.COM wrote: >> Actually, I could really use the ability to use a timer based service >> that had a smaller window than 10 msec. For example, many audio devices >> have crummy interrupt capabilities... its a lot nicer (smoother audio) >> if I have a reliable way to get a periodic running at smaller >> intervals. (5 to 10 msec, but with precision -- the current stuff is >> simply too coarse.) >> >> This would simplify a lot of audio device drivers. And make them more >> robust as well. :-) >> > > > Do they work better if you set "hz" to 1000? (hires_tick)? > > I remember that some devices failed to work when you set hz to 1000 > such as the audio in the Ultra 45 (since fixed) but this was because of > bad code. > > If your driver wants to sleep a short amount of time AND that time is > less then 10ms, that code is hardly ever tested. > > (We should vet all the uses of drv_usectohz() and more sure that the > argument is at least 10000 or that we have an actual reason that we might > want to sleep less) > Yes. There are times when drivers need to sleep for a while to account for chip requirements. Anytime I am faced with a chip based requirement of over 500 usec or so, I will try to use delay() if it works in the context I'm in, to avoid burning CPU cycles on a spin loop. This typically happens during device initialization, such as post firmware initialization delays or during 802.3 autonegotiation. In those cases, we probably *could* just bump the timer up to 1000 usec, but wouldn't it be easier to just verify with tick = 1000? -- Garrett > Casper > > From Darren.Moffat@sun.com Wed Sep 2 07:20:18 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n82EKHfe015647 for ; Wed, 2 Sep 2009 07:20:18 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n82EKF0f000203 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Sep 2009 15:20:17 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPC00J0NL5SW400@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 07:20:16 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPC00EIAL5RSL90@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 07:20:16 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n82EKDKR028730 for ; Wed, 02 Sep 2009 14:20:15 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPC00300KB37E00@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 15:20:08 +0100 (BST) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPC00L73L5CKZ40@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 15:20:01 +0100 (BST) Date: Wed, 02 Sep 2009 15:20:00 +0100 From: Darren J Moffat Subject: Re: PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009] In-reply-to: <1251897983.1943.88.camel@localhost> Sender: Darren.Moffat@sun.com To: Milan Jurik Cc: PSARC-ext Message-id: <4A9E7F10.9080905@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <4A9D90A5.8030905@sun.com> <200909020732.n827WkU8020357@dm-holland-02.uk.sun.com> <4A9E6562.7060801@sun.com> <200909021236.n82CaTTd047884@dm-holland-02.uk.sun.com> <4A9E690B.6090207@sun.com> <4A9E6C05.10800@Sun.COM> <1251897983.1943.88.camel@localhost> User-Agent: Thunderbird 2.0.0.22 (X11/20090804) Status: RO Content-Length: 1559 Milan Jurik wrote: > Hi, > > Darren J Moffat píše v st 02. 09. 2009 v 13:58 +0100: >> Is it safe to assume that this case will update all of the ON and other >> Solaris consolidations that have code that uses lbolt/lbolt64 ? >> >> In the ZFS kernel module alone there are over 30 references to >> lbolt/lblot64. >> >> Was any consideration given to providing something like this: >> >> #define lbolt ddi_get_lbolt() >> #define lbolt64 ddi_get_lbolt64() >> >> The main reason for suggesting is based on a quick glance of where ZFS >> uses lbolt and lbolt64 today those new function calls are going to cause >> some ugly cstyle issues in a few places. >> > > Is it good idea to use macro just to make C-style test happy? Isn't it That is the question I'm asking. The main reason I'm asking is because lbolt/lbolt64 is so so ingrained in existing code. A quick check with cscope suggests somewhere in the region of 500+ references in ON. Is it really a good use of engineering time to fix the cstyle issue that will be created in replacing lbolt with ddi_get_lbolt() as a result ? Personally I don't think so. It is quite a different thing to ask though if use of lbolt is still the appropriate thing to look at post this case and that is valuable use of engineering time. This is mostly below the ARC review line, except for the fact that lbolt/loblt64 are ancient symbols and they are now going away. For what its worth I think it is less of a hack than the nonsense that has to be done sometimes to make lint happy. -- Darren J Moffat From casper@holland.sun.com Wed Sep 2 07:36:57 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n82EavkM015713 for ; Wed, 2 Sep 2009 07:36:57 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n82EauAn017393; Wed, 2 Sep 2009 07:36:57 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPC00K1PLXLUS00@nwk-avmta-2.sfbay.sun.com>; Wed, 02 Sep 2009 07:36:57 -0700 (PDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPC00EL4LXJSO90@nwk-avmta-2.sfbay.sun.com>; Wed, 02 Sep 2009 07:36:56 -0700 (PDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n82EameW025364; Wed, 02 Sep 2009 15:36:48 +0100 (BST) Date: Wed, 02 Sep 2009 16:36:48 +0200 From: Casper.Dik@sun.com Subject: Re: PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009] In-reply-to: <4A9E7EE7.5010505@sun.com> Sender: casper@holland.sun.com To: "Garrett D'Amore" Cc: Joerg Schilling , Rafael.Vanoni@sun.com, PSARC-ext@sun.com, Jerry.Gilliam@sun.com, Steve.Sistare@sun.com, Madhavan.Venkataraman@sun.com, Eric.Saxe@sun.com Message-id: <200909021436.n82EameW025364@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A9D90A5.8030905@sun.com> <4a9d9927./ZRbLvLmxk+UnZdT%Joerg.Schilling@fokus.fraunhofer.de> <4A9DA0C9.1020502@sun.com> <200909020743.n827hefL023517@dm-holland-02.uk.sun.com> <4A9E7EE7.5010505@sun.com> Status: RO Content-Length: 283 >In those cases, we probably *could* just bump the timer up to 1000 usec, >but wouldn't it be easier to just verify with tick = 1000? Fair enough, but it is clear that not every does this when developing kernels; perhaps the debug kernel must default to a 1000Hz tick? Casper From gdamore@sun.com Wed Sep 2 07:50:58 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n82EowAQ015896 for ; Wed, 2 Sep 2009 07:50:58 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n82EovLq026268 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Sep 2009 07:50:58 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPC00L1DMKXPP00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 07:50:57 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPC00EIXMKWSOB0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 07:50:56 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n82EouiA001902 for ; Wed, 02 Sep 2009 07:50:56 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPC00H00MC6OH00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 07:50:56 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPC00MESMKUR600@fe-sfbay-10.sun.com>; Wed, 02 Sep 2009 07:50:56 -0700 (PDT) Date: Wed, 02 Sep 2009 07:50:54 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009] In-reply-to: <200909021436.n82EameW025364@dm-holland-02.uk.sun.com> Sender: Garrett.Damore@sun.com To: Casper.Dik@sun.com Cc: Joerg Schilling , Rafael.Vanoni@sun.com, PSARC-ext@sun.com, Jerry.Gilliam@sun.com, Steve.Sistare@sun.com, Madhavan.Venkataraman@sun.com, Eric.Saxe@sun.com Message-id: <4A9E864E.9050005@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A9D90A5.8030905@sun.com> <4a9d9927./ZRbLvLmxk+UnZdT%Joerg.Schilling@fokus.fraunhofer.de> <4A9DA0C9.1020502@sun.com> <200909020743.n827hefL023517@dm-holland-02.uk.sun.com> <4A9E7EE7.5010505@sun.com> <200909021436.n82EameW025364@dm-holland-02.uk.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 641 Casper.Dik@Sun.COM wrote: > >> In those cases, we probably *could* just bump the timer up to 1000 usec, >> but wouldn't it be easier to just verify with tick = 1000? >> > > > Fair enough, but it is clear that not every does this when developing > kernels; perhaps the debug kernel must default to a 1000Hz tick? > > Casper > > I actually like this: make debug 1000 Hz. I'm wondering if we are approaching the point when it might make sense to make this the default anyway. 100 Hz is pretty darned infrequent, and making things wait for one to two ticks adds enough latency that it makes some things painful. - Garrett From Madhavan.Venkataraman@Sun.COM Wed Sep 2 08:13:37 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n82FDb7l005935 for ; Wed, 2 Sep 2009 08:13:37 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n82FDbcC006034 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Sep 2009 08:13:37 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPC00303NMM7C00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 09:13:34 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPC00M1ENMIV630@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 09:13:34 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n82FDUjj007116 for ; Wed, 02 Sep 2009 08:13:30 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPC00400NLHCU00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 08:13:30 -0700 (PDT) Received: from [129.153.224.5] ([unknown] [129.153.224.5]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPC00MVCNMCBH80@fe-sfbay-10.sun.com>; Wed, 02 Sep 2009 08:13:26 -0700 (PDT) Date: Wed, 02 Sep 2009 10:13:24 -0500 From: Madhavan Venkataraman Subject: Re: PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009] In-reply-to: <4A9DA0C9.1020502@sun.com> Sender: Madhavan.Venkataraman@Sun.COM To: "Garrett D'Amore" Cc: Joerg Schilling , Rafael.Vanoni@Sun.COM, PSARC-ext@Sun.COM, Jerry.Gilliam@Sun.COM, Steve.Sistare@Sun.COM, Eric.Saxe@Sun.COM Reply-to: Madhavan.Venkataraman@Sun.COM Message-id: <4A9E8B94.5040600@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A9D90A5.8030905@sun.com> <4a9d9927./ZRbLvLmxk+UnZdT%Joerg.Schilling@fokus.fraunhofer.de> <4A9DA0C9.1020502@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090311) Status: RO Content-Length: 2151 On 09/01/09 17:31, Garrett D'Amore wrote: > Joerg Schilling wrote: >> Jerry Gilliam wrote: >> >> >>> 2. Project Summary >>> 2.1. Project Description: >>> The tickless project aims at implementing the services >>> provided by the >>> clock cyclic in an event driven fashion. The first >>> sub-project is the >>> decoupling of the lbolt and lbolt64 variables from clock(). >>> These two >>> variables are incremented at each firing of the clock cyclic >>> and provide >>> a time reference to the system. They are being replaced by >>> two routines >>> that are backed by gethrtime(), the existing ddi_get_lbolt() >>> and >>> the new ddi_get_lbolt64(), introduced as a migration path >>> for existing >>> non-DDI compliant consumers. >>> >> >> If this results in being able to sleep with less than 10 ms >> granularity without >> setting a high-res tick, you get many + from me! >> > > Actually, I could really use the ability to use a timer based service > that had a smaller window than 10 msec. For example, many audio > devices have crummy interrupt capabilities... its a lot nicer > (smoother audio) if I have a reliable way to get a periodic running at > smaller intervals. (5 to 10 msec, but with precision -- the current > stuff is simply too coarse.) > > This would simplify a lot of audio device drivers. And make them more > robust as well. :-) > > - Garrett > The callout subsystem has been redesigned to support small and high resolution timers. The condition variable module has also been enhanced to make use of the high resolution timers. (see functions that end with _hires in condvar.c). However, this is not exported via DDI. If some consolidation private driver wants to cheat and use these interfaces (ugh), it can. But if you feel there is a real need, someone should work to export the hires CV interfaces to DDI. What I am saying is that the functionality is there. It just needs to be exported. Of course, it is outside the scope of what Rafael is doing. Someone else has to bell the cat. Madhavan From gdamore@sun.com Wed Sep 2 09:09:18 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n82G9IEc026094 for ; Wed, 2 Sep 2009 09:09:18 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n82G90pe009410 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Sep 2009 09:09:17 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPC0081BQ7FMX00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 10:09:15 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPC00MUDQ7FV480@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 10:09:15 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n82G9EWO010793 for ; Wed, 02 Sep 2009 09:09:14 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPC00800P85HU00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 09:09:14 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPC00D24Q6ZOZE0@fe-sfbay-10.sun.com>; Wed, 02 Sep 2009 09:08:59 -0700 (PDT) Date: Wed, 02 Sep 2009 09:08:59 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009] In-reply-to: <4A9E8B94.5040600@Sun.COM> Sender: Garrett.Damore@sun.com To: Madhavan.Venkataraman@sun.com Cc: Joerg Schilling , Rafael.Vanoni@sun.com, PSARC-ext@sun.com, Jerry.Gilliam@sun.com, Steve.Sistare@sun.com, Eric.Saxe@sun.com Message-id: <4A9E989B.7050207@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A9D90A5.8030905@sun.com> <4a9d9927./ZRbLvLmxk+UnZdT%Joerg.Schilling@fokus.fraunhofer.de> <4A9DA0C9.1020502@sun.com> <4A9E8B94.5040600@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 2366 Madhavan Venkataraman wrote: > On 09/01/09 17:31, Garrett D'Amore wrote: >> Joerg Schilling wrote: >>> Jerry Gilliam wrote: >>> >>> >>>> 2. Project Summary >>>> 2.1. Project Description: >>>> The tickless project aims at implementing the services >>>> provided by the >>>> clock cyclic in an event driven fashion. The first >>>> sub-project is the >>>> decoupling of the lbolt and lbolt64 variables from clock(). >>>> These two >>>> variables are incremented at each firing of the clock >>>> cyclic and provide >>>> a time reference to the system. They are being replaced by >>>> two routines >>>> that are backed by gethrtime(), the existing >>>> ddi_get_lbolt() and >>>> the new ddi_get_lbolt64(), introduced as a migration path >>>> for existing >>>> non-DDI compliant consumers. >>>> >>> >>> If this results in being able to sleep with less than 10 ms >>> granularity without >>> setting a high-res tick, you get many + from me! >>> >> >> Actually, I could really use the ability to use a timer based service >> that had a smaller window than 10 msec. For example, many audio >> devices have crummy interrupt capabilities... its a lot nicer >> (smoother audio) if I have a reliable way to get a periodic running >> at smaller intervals. (5 to 10 msec, but with precision -- the >> current stuff is simply too coarse.) >> >> This would simplify a lot of audio device drivers. And make them >> more robust as well. :-) >> >> - Garrett >> > The callout subsystem has been redesigned to support small and high > resolution > timers. The condition variable module has also been enhanced to make > use of the > high resolution timers. (see functions that end with _hires in > condvar.c). However, > this is not exported via DDI. If some consolidation private driver > wants to cheat > and use these interfaces (ugh), it can. But if you feel there is a > real need, someone > should work to export the hires CV interfaces to DDI. What I am saying > is that > the functionality is there. It just needs to be exported. Can I use fine grained timers with ddi_periodic()? Or is it still only tick granularity? - Garrett > > Of course, it is outside the scope of what Rafael is doing. Someone > else has to > bell the cat. > > Madhavan From Madhavan.Venkataraman@Sun.COM Wed Sep 2 09:25:57 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n82GPun4026655 for ; Wed, 2 Sep 2009 09:25:57 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n82GPhsv016972 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Sep 2009 17:25:56 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPC00C03QZ5UR00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 09:25:53 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPC00B7HQZ59N40@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 09:25:53 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n82GPr3Q012802 for ; Wed, 02 Sep 2009 09:25:53 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPC00800QRTEU00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 09:25:53 -0700 (PDT) Received: from [129.153.224.5] ([unknown] [129.153.224.5]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPC00MLXQYYBHC0@fe-sfbay-10.sun.com>; Wed, 02 Sep 2009 09:25:48 -0700 (PDT) Date: Wed, 02 Sep 2009 11:25:46 -0500 From: Madhavan Venkataraman Subject: Re: PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009] In-reply-to: <4A9E989B.7050207@sun.com> Sender: Madhavan.Venkataraman@Sun.COM To: "Garrett D'Amore" Cc: Joerg Schilling , Rafael.Vanoni@Sun.COM, PSARC-ext@Sun.COM, Jerry.Gilliam@Sun.COM, Steve.Sistare@Sun.COM, Eric.Saxe@Sun.COM Reply-to: Madhavan.Venkataraman@Sun.COM Message-id: <4A9E9C8A.8040209@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A9D90A5.8030905@sun.com> <4a9d9927./ZRbLvLmxk+UnZdT%Joerg.Schilling@fokus.fraunhofer.de> <4A9DA0C9.1020502@sun.com> <4A9E8B94.5040600@Sun.COM> <4A9E989B.7050207@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090311) Status: RO Content-Length: 2725 On 09/02/09 11:08, Garrett D'Amore wrote: > Madhavan Venkataraman wrote: >> On 09/01/09 17:31, Garrett D'Amore wrote: >>> Joerg Schilling wrote: >>>> Jerry Gilliam wrote: >>>> >>>> >>>>> 2. Project Summary >>>>> 2.1. Project Description: >>>>> The tickless project aims at implementing the services >>>>> provided by the >>>>> clock cyclic in an event driven fashion. The first >>>>> sub-project is the >>>>> decoupling of the lbolt and lbolt64 variables from >>>>> clock(). These two >>>>> variables are incremented at each firing of the clock >>>>> cyclic and provide >>>>> a time reference to the system. They are being replaced by >>>>> two routines >>>>> that are backed by gethrtime(), the existing >>>>> ddi_get_lbolt() and >>>>> the new ddi_get_lbolt64(), introduced as a migration path >>>>> for existing >>>>> non-DDI compliant consumers. >>>>> >>>> >>>> If this results in being able to sleep with less than 10 ms >>>> granularity without >>>> setting a high-res tick, you get many + from me! >>>> >>> >>> Actually, I could really use the ability to use a timer based >>> service that had a smaller window than 10 msec. For example, many >>> audio devices have crummy interrupt capabilities... its a lot nicer >>> (smoother audio) if I have a reliable way to get a periodic running >>> at smaller intervals. (5 to 10 msec, but with precision -- the >>> current stuff is simply too coarse.) >>> >>> This would simplify a lot of audio device drivers. And make them >>> more robust as well. :-) >>> >>> - Garrett >>> >> The callout subsystem has been redesigned to support small and high >> resolution >> timers. The condition variable module has also been enhanced to make >> use of the >> high resolution timers. (see functions that end with _hires in >> condvar.c). However, >> this is not exported via DDI. If some consolidation private driver >> wants to cheat >> and use these interfaces (ugh), it can. But if you feel there is a >> real need, someone >> should work to export the hires CV interfaces to DDI. What I am >> saying is that >> the functionality is there. It just needs to be exported. > > Can I use fine grained timers with ddi_periodic()? Or is it still > only tick granularity? Unfortunately not. It only supports 10 millisecond granularity even if hires_tick is set. The interface itself accepts hrtime_t. But internally, the interval is rounded up to the nearest 10 ms boundary. That whole interface needs to be revisited and its implementation revamped. A whole timer subsystem has been implemented there with many issues. But that is a separate topic. Madhavan From gdamore@Sun.COM Wed Sep 2 09:35:41 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n82GZfN3026975 for ; Wed, 2 Sep 2009 09:35:41 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n82GZc9g026435 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Sep 2009 09:35:40 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPC00D0NRFEX900@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 09:35:38 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPC00B3YRFD9N80@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 09:35:37 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n82GZWSf017579 for ; Wed, 02 Sep 2009 09:35:37 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPC00K00R7I5300@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 09:35:33 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPC005B4RF8WB60@fe-sfbay-10.sun.com>; Wed, 02 Sep 2009 09:35:33 -0700 (PDT) Date: Wed, 02 Sep 2009 09:35:32 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009] In-reply-to: <4A9E9C8A.8040209@Sun.COM> Sender: Garrett.Damore@Sun.COM To: Madhavan.Venkataraman@Sun.COM Cc: Joerg Schilling , Rafael.Vanoni@Sun.COM, PSARC-ext@Sun.COM, Jerry.Gilliam@Sun.COM, Steve.Sistare@Sun.COM, Eric.Saxe@Sun.COM Message-id: <4A9E9ED4.4090306@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A9D90A5.8030905@sun.com> <4a9d9927./ZRbLvLmxk+UnZdT%Joerg.Schilling@fokus.fraunhofer.de> <4A9DA0C9.1020502@sun.com> <4A9E8B94.5040600@Sun.COM> <4A9E989B.7050207@sun.com> <4A9E9C8A.8040209@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 3364 Madhavan Venkataraman wrote: > On 09/02/09 11:08, Garrett D'Amore wrote: >> Madhavan Venkataraman wrote: >>> On 09/01/09 17:31, Garrett D'Amore wrote: >>>> Joerg Schilling wrote: >>>>> Jerry Gilliam wrote: >>>>> >>>>> >>>>>> 2. Project Summary >>>>>> 2.1. Project Description: >>>>>> The tickless project aims at implementing the services >>>>>> provided by the >>>>>> clock cyclic in an event driven fashion. The first >>>>>> sub-project is the >>>>>> decoupling of the lbolt and lbolt64 variables from >>>>>> clock(). These two >>>>>> variables are incremented at each firing of the clock >>>>>> cyclic and provide >>>>>> a time reference to the system. They are being replaced >>>>>> by two routines >>>>>> that are backed by gethrtime(), the existing >>>>>> ddi_get_lbolt() and >>>>>> the new ddi_get_lbolt64(), introduced as a migration path >>>>>> for existing >>>>>> non-DDI compliant consumers. >>>>>> >>>>> >>>>> If this results in being able to sleep with less than 10 ms >>>>> granularity without >>>>> setting a high-res tick, you get many + from me! >>>>> >>>> >>>> Actually, I could really use the ability to use a timer based >>>> service that had a smaller window than 10 msec. For example, many >>>> audio devices have crummy interrupt capabilities... its a lot nicer >>>> (smoother audio) if I have a reliable way to get a periodic running >>>> at smaller intervals. (5 to 10 msec, but with precision -- the >>>> current stuff is simply too coarse.) >>>> >>>> This would simplify a lot of audio device drivers. And make them >>>> more robust as well. :-) >>>> >>>> - Garrett >>>> >>> The callout subsystem has been redesigned to support small and high >>> resolution >>> timers. The condition variable module has also been enhanced to make >>> use of the >>> high resolution timers. (see functions that end with _hires in >>> condvar.c). However, >>> this is not exported via DDI. If some consolidation private driver >>> wants to cheat >>> and use these interfaces (ugh), it can. But if you feel there is a >>> real need, someone >>> should work to export the hires CV interfaces to DDI. What I am >>> saying is that >>> the functionality is there. It just needs to be exported. >> >> Can I use fine grained timers with ddi_periodic()? Or is it still >> only tick granularity? > Unfortunately not. It only supports 10 millisecond granularity > even if hires_tick is set. The interface itself accepts hrtime_t. > But internally, the interval is rounded up to the nearest > 10 ms boundary. That whole interface needs to be revisited and > its implementation revamped. A whole timer subsystem has been > implemented there with many issues. But that is a separate topic. So what I need, at least for audio drivers, is a periodic style interface that allows me to specify smaller time windows. One more question: does the periodic reliably execute on 10 msec boundaries, or is it just some random boundary between 10 and 20 msec? For audio purposes, I can probably live with 10 msec *if* it is reliably called at 100 Hz (+/- a reasonable margin of error -- say 1 msec). If it is less frequent than that, or somewhat randomly timed, then it isn't precise enough for audio purposes. - Garrett > > Madhavan From eota@sun.com Wed Sep 2 09:49:50 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n82GnnkJ000123 for ; Wed, 2 Sep 2009 09:49:49 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n82GnaVc014714; Thu, 3 Sep 2009 00:49:41 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPC00F0NS2RM500@nwk-avmta-1.sfbay.Sun.COM>; Wed, 02 Sep 2009 09:49:39 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPC00B4HS2R9LD0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 02 Sep 2009 09:49:39 -0700 (PDT) Received: from localhost (ota.SFBay.Sun.COM [129.146.226.183]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n82GncC4242844; Wed, 02 Sep 2009 09:49:38 -0700 (PDT) Date: Wed, 02 Sep 2009 09:47:53 -0700 From: eiji.ota@sun.com Subject: Re: PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009] In-reply-to: <4A9E9ED4.4090306@sun.com> Sender: Eiji Ota To: gdamore@sun.com Cc: Madhavan.Venkataraman@sun.com, Joerg.Schilling@fokus.fraunhofer.de, Rafael.Vanoni@sun.com, PSARC-ext@sun.com, Jerry.Gilliam@sun.com, Steve.Sistare@sun.com, Eric.Saxe@sun.com Message-id: <20090902094753B.eota@sun.com> MIME-version: 1.0 X-Mailer: Mew version 1.94.2 on XEmacs 21.1 (Cuyahoga Valley) Content-type: Text/Plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Lines: 17 References: <4A9E989B.7050207@sun.com> <4A9E9C8A.8040209@Sun.COM> <4A9E9ED4.4090306@sun.com> X-Dispatcher: imput version 20000228(IM140) Status: RO Content-Length: 569 Garrett, > > One more question: does the periodic reliably execute on 10 msec > boundaries, or is it just some random boundary between 10 and 20 msec? Currently it runs on the 10msec (or multiples of 10msec) edge. > For audio purposes, I can probably live with 10 msec *if* it is reliably > called at 100 Hz (+/- a reasonable margin of error -- say 1 msec). If > it is less frequent than that, or somewhat randomly timed, then it isn't > precise enough for audio purposes. I expect the current one is tolerable for your purpose. If not, let me know. -Eiji From Madhavan.Venkataraman@sun.com Wed Sep 2 09:56:46 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n82GukZH000712 for ; Wed, 2 Sep 2009 09:56:46 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n82GukEN009040 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Sep 2009 09:56:46 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPC00G0BSELJE00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 09:56:45 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPC00BF1SEJ9NF0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 09:56:44 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n82Guh9V016858 for ; Wed, 02 Sep 2009 09:56:43 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPC00N00S6R1U00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 09:56:43 -0700 (PDT) Received: from [129.153.224.5] ([unknown] [129.153.224.5]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPC00ERJSEDHY20@fe-sfbay-09.sun.com>; Wed, 02 Sep 2009 09:56:39 -0700 (PDT) Date: Wed, 02 Sep 2009 11:56:37 -0500 From: Madhavan Venkataraman Subject: Re: PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009] In-reply-to: <4A9E9ED4.4090306@sun.com> Sender: Madhavan.Venkataraman@sun.com To: "Garrett D'Amore" Cc: Joerg Schilling , Rafael.Vanoni@sun.com, PSARC-ext@sun.com, Jerry.Gilliam@sun.com, Steve.Sistare@sun.com, Eric.Saxe@sun.com Reply-to: Madhavan.Venkataraman@sun.com Message-id: <4A9EA3C5.2080803@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A9D90A5.8030905@sun.com> <4a9d9927./ZRbLvLmxk+UnZdT%Joerg.Schilling@fokus.fraunhofer.de> <4A9DA0C9.1020502@sun.com> <4A9E8B94.5040600@Sun.COM> <4A9E989B.7050207@sun.com> <4A9E9C8A.8040209@Sun.COM> <4A9E9ED4.4090306@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090311) Status: RO Content-Length: 4204 On 09/02/09 11:35, Garrett D'Amore wrote: > Madhavan Venkataraman wrote: >> On 09/02/09 11:08, Garrett D'Amore wrote: >>> Madhavan Venkataraman wrote: >>>> On 09/01/09 17:31, Garrett D'Amore wrote: >>>>> Joerg Schilling wrote: >>>>>> Jerry Gilliam wrote: >>>>>> >>>>>> >>>>>>> 2. Project Summary >>>>>>> 2.1. Project Description: >>>>>>> The tickless project aims at implementing the services >>>>>>> provided by the >>>>>>> clock cyclic in an event driven fashion. The first >>>>>>> sub-project is the >>>>>>> decoupling of the lbolt and lbolt64 variables from >>>>>>> clock(). These two >>>>>>> variables are incremented at each firing of the clock >>>>>>> cyclic and provide >>>>>>> a time reference to the system. They are being replaced >>>>>>> by two routines >>>>>>> that are backed by gethrtime(), the existing >>>>>>> ddi_get_lbolt() and >>>>>>> the new ddi_get_lbolt64(), introduced as a migration >>>>>>> path for existing >>>>>>> non-DDI compliant consumers. >>>>>>> >>>>>> >>>>>> If this results in being able to sleep with less than 10 ms >>>>>> granularity without >>>>>> setting a high-res tick, you get many + from me! >>>>>> >>>>> >>>>> Actually, I could really use the ability to use a timer based >>>>> service that had a smaller window than 10 msec. For example, many >>>>> audio devices have crummy interrupt capabilities... its a lot >>>>> nicer (smoother audio) if I have a reliable way to get a periodic >>>>> running at smaller intervals. (5 to 10 msec, but with precision >>>>> -- the current stuff is simply too coarse.) >>>>> >>>>> This would simplify a lot of audio device drivers. And make them >>>>> more robust as well. :-) >>>>> >>>>> - Garrett >>>>> >>>> The callout subsystem has been redesigned to support small and high >>>> resolution >>>> timers. The condition variable module has also been enhanced to >>>> make use of the >>>> high resolution timers. (see functions that end with _hires in >>>> condvar.c). However, >>>> this is not exported via DDI. If some consolidation private driver >>>> wants to cheat >>>> and use these interfaces (ugh), it can. But if you feel there is a >>>> real need, someone >>>> should work to export the hires CV interfaces to DDI. What I am >>>> saying is that >>>> the functionality is there. It just needs to be exported. >>> >>> Can I use fine grained timers with ddi_periodic()? Or is it still >>> only tick granularity? >> Unfortunately not. It only supports 10 millisecond granularity >> even if hires_tick is set. The interface itself accepts hrtime_t. >> But internally, the interval is rounded up to the nearest >> 10 ms boundary. That whole interface needs to be revisited and >> its implementation revamped. A whole timer subsystem has been >> implemented there with many issues. But that is a separate topic. > > So what I need, at least for audio drivers, is a periodic style > interface that allows me to specify smaller time windows. > > One more question: does the periodic reliably execute on 10 msec > boundaries, or is it just some random boundary between 10 and 20 msec? > > For audio purposes, I can probably live with 10 msec *if* it is > reliably called at 100 Hz (+/- a reasonable margin of error -- say 1 > msec). If it is less frequent than that, or somewhat randomly timed, > then it isn't precise enough for audio purposes. The expiration is also rounded up to 10 ms boundaries. So, it would be a random thing between 10 and 20 ms. Since audio drivers require this, you can file a CR against ddi_periodic_add() and assign a high enough priority to it to get someone to fix that. Steve Sistare has shared some thoughts on how to fix the implementation with the original implementor. Maybe, with a priority CR, the original implementor may be willing to reimplement this based on your requirements. We can all add our thoughts to the CR and get someone to fix this. From a power management perspective as well, this interface does not work well. The tickless clock team will be thrilled to have someone work on this to fix it the way it should be fixed. Madhavan From Rafael.Vanoni@sun.com Wed Sep 2 11:06:00 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n82I5x21003292 for ; Wed, 2 Sep 2009 11:06:00 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n82I5rux022347 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Sep 2009 19:05:59 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KPC00K0FVLYC800@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 12:05:58 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KPC00GIJVLWJA40@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 12:05:56 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n82I5thF000015 for ; Wed, 02 Sep 2009 11:05:55 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPC00100UICF100@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Sep 2009 11:05:55 -0700 (PDT) Received: from [10.0.255.219] ([unknown] [192.18.41.196]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPC006LWVLOZZ80@fe-sfbay-10.sun.com>; Wed, 02 Sep 2009 11:05:48 -0700 (PDT) Date: Wed, 02 Sep 2009 11:05:48 -0700 From: Rafael Vanoni Subject: Re: PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling [Fasttrack timeout 09/09/2009] In-reply-to: <4A9E6C05.10800@Sun.COM> Sender: Rafael.Vanoni@sun.com To: Darren J Moffat Cc: Steve Sistare , Jerry Gilliam , PSARC-ext@sun.com, Eric Saxe , Madhavan.Venkataraman@sun.com Message-id: <4A9EB3FC.5000404@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A9D90A5.8030905@sun.com> <200909020732.n827WkU8020357@dm-holland-02.uk.sun.com> <4A9E6562.7060801@sun.com> <200909021236.n82CaTTd047884@dm-holland-02.uk.sun.com> <4A9E690B.6090207@sun.com> <4A9E6C05.10800@Sun.COM> User-Agent: Thunderbird 2.0.0.22 (X11/20090804) Status: RO Content-Length: 1225 Darren J Moffat wrote: > Is it safe to assume that this case will update all of the ON and other > Solaris consolidations that have code that uses lbolt/lbolt64 ? We're updating all of ON with our putback, and we've been looking out for modules in other consolidations that reference them (6868799 and 6878074 are two examples of that). Our testing plan[1] is also helping us find instances of that problem. We've been in touch with RPE and ISV to make sure they know about this change, and to identify partners that should update their modules. > In the ZFS kernel module alone there are over 30 references to > lbolt/lblot64. > > Was any consideration given to providing something like this: > > #define lbolt ddi_get_lbolt() > #define lbolt64 ddi_get_lbolt64() > > The main reason for suggesting is based on a quick glance of where ZFS > uses lbolt and lbolt64 today those new function calls are going to cause > some ugly cstyle issues in a few places. We're making sure our changes clear cstyle and all pbchks. If there's a particular file or change you think can cause problems, please let us know. Thanks, Rafael [1]http://www.opensolaris.org/os/project/tickless/Testing/clock_and_lbolt/ From jerry.gilliam@sun.com Tue Sep 15 14:58:41 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8FLweev009400 for ; Tue, 15 Sep 2009 14:58:40 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n8FLwSKb012664; Wed, 16 Sep 2009 05:58:34 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQ100J0191JWZ00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 15 Sep 2009 14:58:31 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQ100BYH91JYL30@nwk-avmta-1.sfbay.Sun.COM>; Tue, 15 Sep 2009 14:58:31 -0700 (PDT) Received: from [129.146.226.92] (tethys.SFBay.Sun.COM [129.146.226.92]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n8FLwVwB597952; Tue, 15 Sep 2009 14:58:31 -0700 (PDT) Date: Tue, 15 Sep 2009 14:53:51 -0700 From: Jerry Gilliam Subject: Re: PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling, [Fasttrack timeout 09/09/2009] To: PSARC-ext@sun.com, Rafael Vanoni Cc: Eric Saxe , Madhavan.Venkataraman@sun.com, Steven Sistare Message-id: <4AB00CEF.6010703@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 79 This case has timed out and I've now marked the case as approved. thx, -jg From gdamore@sun.com Tue Sep 15 16:00:53 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8FN0qsA027091 for ; Tue, 15 Sep 2009 16:00:52 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n8FN0lDs011024 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 16 Sep 2009 07:00:51 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQ100501BXC9I00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 15 Sep 2009 16:00:48 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQ100BS2BXCYM70@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 15 Sep 2009 16:00:48 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n8FN0mrS009000 for ; Tue, 15 Sep 2009 16:00:48 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KQ100100BL24400@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 15 Sep 2009 16:00:48 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KQ100397BXBZV10@fe-sfbay-09.sun.com>; Tue, 15 Sep 2009 16:00:48 -0700 (PDT) Date: Tue, 15 Sep 2009 16:00:47 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2009/396 Tickless Kernel Architecture / lbolt decoupling, [Fasttrack timeout 09/09/2009] In-reply-to: <4AB00CEF.6010703@sun.com> Sender: Garrett.Damore@sun.com To: Jerry Gilliam Cc: PSARC-ext@sun.com, Rafael Vanoni , Eric Saxe , Madhavan.Venkataraman@sun.com, Steven Sistare Message-id: <4AB01C9F.20704@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4AB00CEF.6010703@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 199 Jerry Gilliam wrote: > > This case has timed out and I've now marked the case as approved. > > > thx, > -jg > Actually, the case was approved during the last regular PSARC meeting :-) - Garrett