From sacadmin Fri Jul 6 14:45:41 2007 Received: from jurassic.eng.sun.com (jurassic-226-b [129.146.226.130]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l66LjfnW008880; Fri, 6 Jul 2007 14:45:41 -0700 (PDT) Received: from tethys (tethys.SFBay.Sun.COM [129.146.226.92]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id l66Lhkb1769970; Fri, 6 Jul 2007 14:43:47 -0700 (PDT) Message-Id: <200707062143.l66Lhkb1769970@jurassic.eng.sun.com> Date: Fri, 6 Jul 2007 14:42:49 -0700 (PDT) From: Jerry Gilliam Reply-To: Jerry Gilliam Subject: Driver Periodic Timeouts [PSARC/2007/402 FastTrack timeout 07/13/2007] To: PSARC-record@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: CuXfqBT4+7IX6kHh1weY8Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_64 SunOS 5.11 sun4u sparc Status: RO Content-Length: 554 Template Version: @(#)sac_nextcase 1.63 06/14/07 SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Driver Periodic Timeouts 1.2. Name of Document Author/Supplier: Author: Eiji Ota 1.3 Date of This Document: 06 July, 2007 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From sacadmin Fri Jul 6 14:52:56 2007 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 l66LquUc009033 for ; Fri, 6 Jul 2007 14:52:56 -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 l66Lp15S018156; Fri, 6 Jul 2007 14:51:01 -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 <0JKS00E05210G100@brm-avmta-1.central.sun.com>; Fri, 06 Jul 2007 15:51:00 -0600 (MDT) Received: from jurassic.eng.sun.com ([129.146.106.105]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKS00C8Z20ZIF20@brm-avmta-1.central.sun.com>; Fri, 06 Jul 2007 15:50:59 -0600 (MDT) Received: from tethys (tethys.SFBay.Sun.COM [129.146.226.92]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id l66Lowwr770052; Fri, 06 Jul 2007 14:50:59 -0700 (PDT) Date: Fri, 06 Jul 2007 14:50:01 -0700 (PDT) From: Jerry Gilliam Subject: 2007/402: Driver Periodic Timeouts To: Eiji.Ota@sun.com, psarc@sun.com Cc: Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Roch.Bourbonnais@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, Dan.Mick@sun.com, pl-direct@sun.com Reply-to: Jerry Gilliam Message-id: <200707062150.l66Lowwr770052@jurassic.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_64 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: IWptgl8qFuUZ0Qt24NZV3g== X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 12239 I am submitting this fast-track on behalf of Eiji Ota, with timeout set to 07/13/2007. The project desires patch/minor binding for the proposed interfaces. thx, -jg 0. Abstract This is a proposal to provide the timeout interface for periodic timeout requests with adding more interrupt contexts to the callback functions 1. overview Since timeout(9F) function is the one-time timeout function, device drivers must call timeout(9F) again in their callback functions if they want to issue periodic timeout requests, but this way could be neither efficient nor accurate. Solaris has been able to provide the interval timer based on the cyclic subsystem since it was introduced at PSARC 1999/364 CLOCK_HIGHRES, and some device drivers have used it to issue the periodic timeout requests though there is no official interface yet. This proposal is to provide the DDI interface to issue periodic timeout requests for device drivers. 2. current timeout(9F)/untimeout(9F) problems The current Solaris timeout(9F)/untimeout(9F) have the following problems. Currently device driver developers have to solve them in their own ways if they encounter some of them during their developments. (e.g. calling the cyclic subsystem directly) o no periodic timeout timeout(9F) doesn't support the periodic timeout requests. If a device driver wants to issue periodic timeout requests, timeout(9F) must be called again in its callback function as a workarouond. This is neither efficient nor accurate. o only one callback context timeout(9F) supports only one callback context (kernel context), and if a device driver needs to invoke its callback function in interrupt context (e.g. the real-time application calls the driver routine), timeout(9F) cannot be used for that purpose. (cv_timedwait(9F) should be used instead) o 10ms-tick base timeout timeout(9F) cannot take the nanosecond interval though Solaris supports the high resolution time (hrtime_t). If you want to use timeout(9F) with high resolution time (hrtime_t), you have to round it up (to tick) before calling timeout(9F). 3. Solution The proposed interface is provided to solve the problems above, which gives the following new features. o achieving a periodic timeout o supporting various interrupt context (level 1 to 10) for callback functions o nanosecond (hrtime_t) interval About the detailed specification of the interface, please see 4. Interface Taxonomy and 8. Document below. 4. Interface Taxonomy These interfaces are declared in the header file and . -------------------------------------------------------------------------- Exported Interface | Level | Comments -------------------------------------------------------------------------- ddi_periodic_add | Committed | register a periodic callback function ddi_periodic_delete | Committed | unregister a periodic callback function | | ddi_periodic_t | Committed | Opaque type -------------------------------------------------------------------------- 5. Release binding The requested release binding is micro binding. 6. Current device drivers using the cyclic subsystem in ON There are some device drivers in ON using the cyclic subsystem to issue periodic timeout requests, whose list is below. (Note that the first column is the driver name, then the function name, the interrupt level and the interval time (1) are shown respectively.) All drivers except qcn (2) can call the proposed interface instead not to use the cyclic subsystem directly. -------------------------------------------------------------------------- Driver | Func |Level| Time | Comment -------------------------------------------------------------------------- qcn |qcn_poll_handler |LOW | 5ms | sun4v console driver dmfe |dmfe_cyclic |LOW | 25ms | Davicom DM9102 Network driver todds1337 |todds1337_cyclic |LOW | 1s | serial real-time clock driver rmc_comm |rmc_comm_cyclic |LOW | 5s | rmc service channel driver lombus |lombus_cyclic |LOW | 1s | LOMbus driver todds1307 |i2c_cyclic_timeout|LOW | 1s | serial,i2c real-time clock | | | | driver bge |bge_chip_cyclic |LOCK | 500ms| Broadcom Gb Ethernet driver rge |rge_chip_cyclic |LOCK | 1s | Realtek 1Gb Ethernet driver ixgb |ixgb_chip_cyclic |LOCK | 1.5s | Intel PRO/10GbE driver nge |nge_chip_cyclic |LOCK | 500ms| nVidia 1Gb Ethernet driver bscv |bscv_watchdog_pat_|LOCK | 1s | multi-threaded LOM driver |request | | | ntwdt |ntwdt_cyclic_pat |LOCK | 1s | Netra-1280 watchdog timer | | | | driver ntwdt |ntwdt_cyclic_pat |LOW | 1s | NTWDT watchdog driver -------------------------------------------------------------------------- (1): In case of using the cyclic subsystem, the resolution is the same as the interval time from the implementation. (2): the qcn driver uses 5ms against the old OBP, and this is the only exception that the default resolution (10ms) cannot be used. 7. Reference PSARC 1999/364 CLOCK_HIGHRES PSARC 2004/239 x86 PSMI Extensions for Higher Resolution Timer 4977787 Official DDI interface is required for periodic timeout requests 8. Document 8.1. ddi_periodic_add(9F) Kernel Functions for Drivers ddi_periodic_add(9F) NAME ddi_periodic_add - issue nanosecond periodic timeout requests SYNOPSIS #include #include ddi_periodic_t ddi_periodic_add(void (*func)(void *), void *arg, hrtime_t interval, int level) INTERFACE LEVEL Solaris DDI specific (Solaris DDI) PARAMETERS func: the callback function The callback function will be invoked periodically in the specified interval. The function is invoked in kernel context if the argument level is zero. Otherwise it's invoked in interrupt context at the specified level. arg: the argument passed to the callback function interval: interval time in nanoseconds level : callback interrupt level If the value is zero, the callback function is invoked in kernel context. If the value is more than zero, but less than or equal to ten, the callback function is invoked in interrupt context at the specified interrupt level, which may be used for real time applications. This value must be in range of 0-10. DESCRIPTION ddi_periodic_add(9F) schedules the specified function to be periodically invoked in the nanosecond interval time. As well as timeout(9F), the exact time interval over which the function takes effect cannot be guaranteed, but the value given is a close approximation. RETURN VALUES ddi_periodic_add(9F) returns the non-zero opaque value (ddi_periodic_t), which might be used for ddi_periodic_delete(9F) to specify the request. CONTEXT ddi_periodic_add(9F) can be called in user or kernel context, but it cannot be called in interrupt context, which is different from timeout(9F). EXAMPLES Example 1: Using ddi_periodic_add(9F) for a callback function invoked in kernel context. In the following example, the device driver registers a periodic callback function invoked in kernel context. static void my_periodic_func(void *arg) { /* * This handler is invoked periodically. */ struct my_state *statep = (struct my_state *)arg; mutex_enter(&statep->lock); if (load_unbalanced(statep)) { balance_tasks(statep); } mutex_exit(&statep->lock); } static void start_periodic_timer(struct my_state *statep) { hrtime_t interval = CHECK_INTERVAL; /* * Register my_callback which is invoked periodically * in CHECK_INTERVAL in kernel context. */ statep->periodic_id = ddi_periodic_add(my_periodic_func, statep, interval, 0); } Example 2: Using ddi_periodic_add(9F) for a callback function periodically invoked in interrupt context at level 7. In the following example, the device driver registers a callback function invoked in interrupt context at level 7. /* * This handler is invoked periodically in interrupt context. */ static void my_periodic_int7_func(void *arg) { struct my_state *statep = (struct my_state *)arg; mutex_enter(&statep->lock); monitor_device(statep); mutex_exit(&statep->lock); } static void start_monitor_device(struct my_state *statep) { hrtime_t interval = MONITOR_INTERVAL; /* * Register the callback function invoked periodically * at interrupt level 7. */ statep->periodic_id = ddi_periodic_add(my_periodic_int7_func, statep, interval, 7); } NOTES The actual interval time depends on the clock resolution on the system. The interval less than the clock resolution rounds up to the resolution internally. For example, if the system resolution is 10ms, less than 10ms interval rounds up to 10ms internally. SEE ALSO ddi_periodic_delete(9F), timeout(9F), untimeout(9F), qtimeout(9F), quntimeout(9F), cv_timedwait(9F), delay(9F), drv_usectohz(9F) 8.2. ddi_periodic_delete(9F) Kernel Functions for Drivers ddi_periodic_delete(9F) NAME ddi_periodic_delete - cancel nanosecond periodic timeout requests SYNOPSIS #include #include void ddi_periodic_delete(ddi_periodic_t req) INTERFACE LEVEL Solaris DDI specific (Solaris DDI) PARAMETERS req: ddi_periodic_t opaque value ddi_periodic_add(9F) returned previously. DESCRIPTION ddi_periodic_delete(9F) cancels the ddi_periodic_add(9F) request previously issued. As well as untimeout(9F), calling ddi_periodic_delete(9F) against a periodic timeout request which is either running on another CPU, or has already canceled causes no problems. Unlike untimeout(9F), there is no restrictions on the lock which might be held across the call to ddi_periodic_delete(9F). CONTEXT ddi_periodic_delete(9F) can be called in user or kernel context, but it cannot be called in interrupt context, which is different from untimeout(9F). EXAMPLES In the following example, the device driver cancels the timeout request by calling ddi_periodic_delete() against the request previously issued. /* * Stop the periodic timer */ static void stop_periodic_timer(struct my_state *statep) { ddi_periodic_delete(statep->periodic_id); } static void start_periodic_timer(struct my_state *statep) { hrtime_t interval = CHECK_INTERVAL; /* * Register my_callback which is invoked periodically * in CHECK_INTERVAL in kernel context. */ statep->periodic_id = ddi_periodic_add(my_periodic_func, statep, interval, 0); } static void my_periodic_func(void *arg) { /* * This handler is invoked periodically. */ struct my_state *statep = (struct my_state *)arg; mutex_enter(&statep->lock); if (load_unbalanced(statep)) { balance_tasks(statep); } mutex_exit(&statep->lock); } SEE ALSO ddi_periodic_add(9F), timeout(9F), untimeout(9F), qtimeout(9F), quntimeout(9F), cv_timedwait(9F), delay(9F), drv_usectohz(9F) From sacadmin Mon Jul 9 06:49:46 2007 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 l69Dnj8p023596 for ; Mon, 9 Jul 2007 06:49:46 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l69DlZgi014057; Mon, 9 Jul 2007 21:47:44 +0800 (SGT) 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 <0JKW00I0RZNJOZ00@nwk-avmta-2.sfbay.sun.com>; Mon, 09 Jul 2007 06:47:43 -0700 (PDT) Received: from dm-france-02.uk.sun.com ([129.156.101.220]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKW00LODZNGPN90@nwk-avmta-2.sfbay.sun.com>; Mon, 09 Jul 2007 06:47:41 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by dm-france-02.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l69DlXQw022926; Mon, 09 Jul 2007 14:47:35 +0100 (BST) Received: from corn.Sun.COM (corn [129.157.192.240]) by bebop.France.Sun.COM (8.13.8+Sun/8.13.8) with SMTP id l69DlUGW026467; Mon, 09 Jul 2007 15:47:30 +0200 (MEST) Date: Mon, 09 Jul 2007 15:41:57 +0200 From: Roch - PAE Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <200707062150.l66Lowwr770052@jurassic.eng.sun.com> To: Jerry Gilliam Cc: Eiji.Ota@sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Roch.Bourbonnais@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, Dan.Mick@sun.com, pl-direct@sun.com Message-id: <18066.15141.854128.479603@gargle.gargle.HOWL> Organization: SUN Microsystems MIME-version: 1.0 X-Mailer: VM 7.19 under 21.1 (patch 3) "Acadia" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200707062150.l66Lowwr770052@jurassic.eng.sun.com> Phone: (+33).4.76.18.83.20 (x[70]38320) Status: RO Content-Length: 14019 Jerry Gilliam writes: > > I am submitting this fast-track on behalf of Eiji Ota, > with timeout set to 07/13/2007. The project desires patch/minor > binding for the proposed interfaces. > > thx, > -jg > > > > 0. Abstract > > This is a proposal to provide the timeout interface for periodic timeout > requests with adding more interrupt contexts to the callback functions > > > 1. overview > > Since timeout(9F) function is the one-time timeout function, device drivers > must call timeout(9F) again in their callback functions if they want to issue > periodic timeout requests, but this way could be neither efficient nor > accurate. Solaris has been able to provide the interval timer based on the > cyclic subsystem since it was introduced at PSARC 1999/364 CLOCK_HIGHRES, > and some device drivers have used it to issue the periodic timeout requests > though there is no official interface yet. > > This proposal is to provide the DDI interface to issue periodic timeout > requests for device drivers. > > > 2. current timeout(9F)/untimeout(9F) problems > > The current Solaris timeout(9F)/untimeout(9F) have the following problems. > Currently device driver developers have to solve them in their own ways > if they encounter some of them during their developments. (e.g. calling the > cyclic subsystem directly) > > o no periodic timeout > > timeout(9F) doesn't support the periodic timeout requests. If a device > driver wants to issue periodic timeout requests, timeout(9F) must be > called again in its callback function as a workarouond. This is neither > efficient nor accurate. > > o only one callback context > > timeout(9F) supports only one callback context (kernel context), > and if a device driver needs to invoke its callback function in interrupt > context (e.g. the real-time application calls the driver routine), > timeout(9F) cannot be used for that purpose. (cv_timedwait(9F) should be > used instead) The proposition does not seem to provide callback from a real-time non-interrupt context. Maybe the text should refrain from using "real-time". > > o 10ms-tick base timeout > > timeout(9F) cannot take the nanosecond interval though Solaris > supports the high resolution time (hrtime_t). If you want to use > timeout(9F) with high resolution time (hrtime_t), you have to round it > up (to tick) before calling timeout(9F). > > > 3. Solution > > The proposed interface is provided to solve the problems above, which gives > the following new features. > > o achieving a periodic timeout > o supporting various interrupt context (level 1 to 10) for callback > functions > o nanosecond (hrtime_t) interval > > About the detailed specification of the interface, please see 4. Interface > Taxonomy and 8. Document below. > > > 4. Interface Taxonomy > > These interfaces are declared in the header file and > . > -------------------------------------------------------------------------- > Exported Interface | Level | Comments > -------------------------------------------------------------------------- > ddi_periodic_add | Committed | register a periodic callback function > ddi_periodic_delete | Committed | unregister a periodic callback function > | | > ddi_periodic_t | Committed | Opaque type > -------------------------------------------------------------------------- > > > 5. Release binding > > The requested release binding is micro binding. > > > 6. Current device drivers using the cyclic subsystem in ON > > There are some device drivers in ON using the cyclic subsystem to issue > periodic timeout requests, whose list is below. (Note that the first column > is the driver name, then the function name, the interrupt level and the > interval time (1) are shown respectively.) > > All drivers except qcn (2) can call the proposed interface instead not to > use the cyclic subsystem directly. > -------------------------------------------------------------------------- > Driver | Func |Level| Time | Comment > -------------------------------------------------------------------------- > qcn |qcn_poll_handler |LOW | 5ms | sun4v console driver > dmfe |dmfe_cyclic |LOW | 25ms | Davicom DM9102 Network driver > todds1337 |todds1337_cyclic |LOW | 1s | serial real-time clock driver > rmc_comm |rmc_comm_cyclic |LOW | 5s | rmc service channel driver > lombus |lombus_cyclic |LOW | 1s | LOMbus driver > todds1307 |i2c_cyclic_timeout|LOW | 1s | serial,i2c real-time clock > | | | | driver > bge |bge_chip_cyclic |LOCK | 500ms| Broadcom Gb Ethernet driver > rge |rge_chip_cyclic |LOCK | 1s | Realtek 1Gb Ethernet driver > ixgb |ixgb_chip_cyclic |LOCK | 1.5s | Intel PRO/10GbE driver > nge |nge_chip_cyclic |LOCK | 500ms| nVidia 1Gb Ethernet driver > bscv |bscv_watchdog_pat_|LOCK | 1s | multi-threaded LOM driver > |request | | | > ntwdt |ntwdt_cyclic_pat |LOCK | 1s | Netra-1280 watchdog timer > | | | | driver > ntwdt |ntwdt_cyclic_pat |LOW | 1s | NTWDT watchdog driver > -------------------------------------------------------------------------- > (1): In case of using the cyclic subsystem, the resolution is the same as > the interval time from the implementation. > (2): the qcn driver uses 5ms against the old OBP, and this is the only > exception that the default resolution (10ms) cannot be used. > > > 7. Reference > > PSARC 1999/364 CLOCK_HIGHRES > PSARC 2004/239 x86 PSMI Extensions for Higher Resolution Timer > 4977787 Official DDI interface is required for periodic timeout requests > > > 8. Document > > 8.1. ddi_periodic_add(9F) > > Kernel Functions for Drivers ddi_periodic_add(9F) > > > NAME > ddi_periodic_add - issue nanosecond periodic timeout requests > > > SYNOPSIS > #include > #include > > ddi_periodic_t > ddi_periodic_add(void (*func)(void *), void *arg, hrtime_t interval, > int level) > > > INTERFACE LEVEL > Solaris DDI specific (Solaris DDI) > > > PARAMETERS > func: the callback function > > The callback function will be invoked periodically in the specified > interval. The function is invoked in kernel context if the argument > level is zero. Otherwise it's invoked in interrupt context at the > specified level. > > > arg: the argument passed to the callback function > > > interval: interval time in nanoseconds > Could add text about restrictions on interval (see below). > > level : callback interrupt level > > If the value is zero, the callback function is invoked > in kernel context. If the value is more than zero, but less > than or equal to ten, the callback function is invoked in interrupt > context at the specified interrupt level, which may be used for > real time applications. > > This value must be in range of 0-10. > > DESCRIPTION > ddi_periodic_add(9F) schedules the specified function to be > periodically invoked in the nanosecond interval time. > > As well as timeout(9F), the exact time interval over which the function > takes effect cannot be guaranteed, but the value given is a close > approximation. > > > RETURN VALUES > ddi_periodic_add(9F) returns the non-zero opaque value (ddi_periodic_t), > which might be used for ddi_periodic_delete(9F) to specify the request. > Can we not run out of cyclics supporting lots of different nanosecond intervals ? Is ddi_periodic_add guaranteed to succeed ? > > CONTEXT > ddi_periodic_add(9F) can be called in user or kernel context, but > it cannot be called in interrupt context, which is different from > timeout(9F). > > > EXAMPLES > > Example 1: Using ddi_periodic_add(9F) for a callback function > invoked in kernel context. > > > In the following example, the device driver registers a periodic > callback function invoked in kernel context. > > static void > my_periodic_func(void *arg) > { > /* > * This handler is invoked periodically. > */ > struct my_state *statep = (struct my_state *)arg; > > mutex_enter(&statep->lock); > if (load_unbalanced(statep)) { > balance_tasks(statep); > } > mutex_exit(&statep->lock); > } > > static void > start_periodic_timer(struct my_state *statep) > { > hrtime_t interval = CHECK_INTERVAL; > /* > * Register my_callback which is invoked periodically > * in CHECK_INTERVAL in kernel context. > */ > statep->periodic_id = ddi_periodic_add(my_periodic_func, > statep, interval, 0); > } > > > Example 2: Using ddi_periodic_add(9F) for a callback function > periodically invoked in interrupt context at level 7. > > > In the following example, the device driver registers a callback > function invoked in interrupt context at level 7. > > /* > * This handler is invoked periodically in interrupt context. > */ > static void > my_periodic_int7_func(void *arg) > { > struct my_state *statep = (struct my_state *)arg; > mutex_enter(&statep->lock); > monitor_device(statep); > mutex_exit(&statep->lock); > } > > static void > start_monitor_device(struct my_state *statep) > { > hrtime_t interval = MONITOR_INTERVAL; > /* > * Register the callback function invoked periodically > * at interrupt level 7. > */ > statep->periodic_id = ddi_periodic_add(my_periodic_int7_func, > statep, interval, 7); > } > > > NOTES > The actual interval time depends on the clock resolution on the system. > The interval less than the clock resolution rounds up to the resolution > internally. For example, if the system resolution is 10ms, less than > 10ms interval rounds up to 10ms internally. > So small requested intervals will be rounded up to the clock resolution but larger that clock resolution intervals will not be rounded ? A crazy 1 microsecond request will then be honored with a callback every 10ms. Correct ? Will a 12ms request will be honored with callbacks every 12ms ? -roch > > SEE ALSO > ddi_periodic_delete(9F), timeout(9F), untimeout(9F), qtimeout(9F), > quntimeout(9F), cv_timedwait(9F), delay(9F), drv_usectohz(9F) > > > 8.2. ddi_periodic_delete(9F) > > Kernel Functions for Drivers ddi_periodic_delete(9F) > > > NAME > ddi_periodic_delete - cancel nanosecond periodic timeout requests > > > SYNOPSIS > #include > #include > > void ddi_periodic_delete(ddi_periodic_t req) > > > INTERFACE LEVEL > Solaris DDI specific (Solaris DDI) > > > PARAMETERS > req: ddi_periodic_t opaque value ddi_periodic_add(9F) returned previously. > > > DESCRIPTION > ddi_periodic_delete(9F) cancels the ddi_periodic_add(9F) request > previously issued. > > As well as untimeout(9F), calling ddi_periodic_delete(9F) against a > periodic timeout request which is either running on another CPU, or has > already canceled causes no problems. Unlike untimeout(9F), there is no > restrictions on the lock which might be held across the call to > ddi_periodic_delete(9F). > > > CONTEXT > ddi_periodic_delete(9F) can be called in user or kernel context, but > it cannot be called in interrupt context, which is different from > untimeout(9F). > > > EXAMPLES > In the following example, the device driver cancels the timeout request > by calling ddi_periodic_delete() against the request previously issued. > > /* > * Stop the periodic timer > */ > static void > stop_periodic_timer(struct my_state *statep) > { > ddi_periodic_delete(statep->periodic_id); > } > > static void > start_periodic_timer(struct my_state *statep) > { > hrtime_t interval = CHECK_INTERVAL; > /* > * Register my_callback which is invoked periodically > * in CHECK_INTERVAL in kernel context. > */ > statep->periodic_id = ddi_periodic_add(my_periodic_func, > statep, interval, 0); > } > > static void > my_periodic_func(void *arg) > { > /* > * This handler is invoked periodically. > */ > struct my_state *statep = (struct my_state *)arg; > > mutex_enter(&statep->lock); > if (load_unbalanced(statep)) { > balance_tasks(statep); > } > mutex_exit(&statep->lock); > } > > SEE ALSO > ddi_periodic_add(9F), timeout(9F), untimeout(9F), qtimeout(9F), > quntimeout(9F), cv_timedwait(9F), delay(9F), drv_usectohz(9F) > From sacadmin Mon Jul 9 10:57:05 2007 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 l69Hv4Js001459 for ; Mon, 9 Jul 2007 10:57:05 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l69Hswf0027952; Mon, 9 Jul 2007 18:55:02 +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 <0JKX00J09B3P2D00@brm-avmta-1.central.sun.com>; Mon, 09 Jul 2007 11:55:01 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKX00IR0B3NAY00@brm-avmta-1.central.sun.com>; Mon, 09 Jul 2007 11:55:00 -0600 (MDT) Received: from localhost (ota.SFBay.Sun.COM [129.146.226.183]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l69HsxhT243257; Mon, 09 Jul 2007 10:54:59 -0700 (PDT) Date: Mon, 09 Jul 2007 10:54:58 -0700 (PDT) From: eiji.ota@sun.com Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <18066.15141.854128.479603@gargle.gargle.HOWL> Sender: Eiji Ota To: Roch.Bourbonnais@sun.com Cc: jg@jurassic.sfbay.sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, Dan.Mick@sun.com, pl-direct@sun.com Message-id: <20070709105458K.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.2.0.264296 Lines: 78 References: <200707062150.l66Lowwr770052@jurassic.eng.sun.com> <18066.15141.854128.479603@gargle.gargle.HOWL> X-Dispatcher: imput version 20000228(IM140) Status: RO Content-Length: 3129 Hi, > > o only one callback context > > > > timeout(9F) supports only one callback context (kernel context), > > and if a device driver needs to invoke its callback function in interrupt > > context (e.g. the real-time application calls the driver routine), > > timeout(9F) cannot be used for that purpose. (cv_timedwait(9F) should be > > used instead) > > The proposition does not seem to provide callback from a > real-time non-interrupt context. Maybe the text should > refrain from using "real-time". This is an example here to explain one of restrictions timeout(9F) has, and the man pages don't use this "real-time" word. > > > > interval: interval time in nanoseconds > > > > Could add text about restrictions on interval (see below). I thought NOTES would be a good place where the restriction is described.. > > level : callback interrupt level > > > > If the value is zero, the callback function is invoked > > in kernel context. If the value is more than zero, but less > > than or equal to ten, the callback function is invoked in interrupt > > context at the specified interrupt level, which may be used for > > real time applications. > > > > This value must be in range of 0-10. > > > > DESCRIPTION > > ddi_periodic_add(9F) schedules the specified function to be > > periodically invoked in the nanosecond interval time. > > > > As well as timeout(9F), the exact time interval over which the function > > takes effect cannot be guaranteed, but the value given is a close > > approximation. > > > > > > RETURN VALUES > > ddi_periodic_add(9F) returns the non-zero opaque value (ddi_periodic_t), > > which might be used for ddi_periodic_delete(9F) to specify the request. > > > > Can we not run out of cyclics supporting lots of different > nanosecond intervals ? Is ddi_periodic_add guaranteed to > succeed ? This might be the implementation, but yes ddi_periodic_add() always succeeds like timeout(9F). > > NOTES > > The actual interval time depends on the clock resolution on the system. > > The interval less than the clock resolution rounds up to the resolution > > internally. For example, if the system resolution is 10ms, less than > > 10ms interval rounds up to 10ms internally. > > > > > So small requested intervals will be rounded up to the clock > resolution but larger that clock resolution intervals will > not be rounded ? A crazy 1 microsecond request will then be > honored with a callback every 10ms. Correct ? Will a 12ms > request will be honored with callbacks every 12ms ? The resolution here is the system resolution. If you change it to 1ms (e.g. by setting 1 to hires_tick), then the shortest interval is 1ms, and your 1 ms request can be taken. If you don't change the system resolution (i.e. 10ms currently), it rounds up to 10ms. It explains the shortest interval is the same as the system resolution, and the interval larger than that is not affected. -Eiji From sacadmin Mon Jul 9 14:23:33 2007 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 l69LNWvA011943 for ; Mon, 9 Jul 2007 14:23:32 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l69LLMBq026222; Mon, 9 Jul 2007 22:21:23 +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 <0JKX0010NKNLQ500@nwk-avmta-1.sfbay.Sun.COM>; Mon, 09 Jul 2007 14:21:21 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKX00F70KNKAV60@nwk-avmta-1.sfbay.Sun.COM>; Mon, 09 Jul 2007 14:21:20 -0700 (PDT) Received: from mcescher.eng.sun.com (mcescher.SFBay.Sun.COM [129.146.224.55]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l69LLI8q024140; Mon, 09 Jul 2007 14:21:18 -0700 (PDT) Received: from mcescher.eng.sun.com (localhost [127.0.0.1]) by mcescher.eng.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l69LLI9I213998; Mon, 09 Jul 2007 14:21:18 -0700 (PDT) Received: (from edp@localhost) by mcescher.eng.sun.com (8.14.1+Sun/8.14.1/Submit) id l69LLHmm213997; Mon, 09 Jul 2007 14:21:17 -0700 (PDT) Date: Mon, 09 Jul 2007 14:21:17 -0700 From: Edward Pilatowicz Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <20070709105458K.eota@sun.com> To: eiji.ota@sun.com Cc: Roch.Bourbonnais@sun.com, jg@jurassic.sfbay.sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, Dan.Mick@sun.com, pl-direct@sun.com Message-id: <20070709212117.GD211216@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.2.0.264296 References: <200707062150.l66Lowwr770052@jurassic.eng.sun.com> <18066.15141.854128.479603@gargle.gargle.HOWL> <20070709105458K.eota@sun.com> X-Authentication-warning: mcescher.eng.sun.com: edp set sender to edward.pilatowicz@sun.com using -f User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 1507 On Mon, Jul 09, 2007 at 10:54:58AM -0700, eiji.ota@sun.com wrote: > > > level : callback interrupt level > > > > > > If the value is zero, the callback function is invoked > > > in kernel context. If the value is more than zero, but less > > > than or equal to ten, the callback function is invoked in interrupt > > > context at the specified interrupt level, which may be used for > > > real time applications. > > > > > > This value must be in range of 0-10. > > > > > > DESCRIPTION > > > ddi_periodic_add(9F) schedules the specified function to be > > > periodically invoked in the nanosecond interval time. > > > > > > As well as timeout(9F), the exact time interval over which the function > > > takes effect cannot be guaranteed, but the value given is a close > > > approximation. > > > > > > > > > RETURN VALUES > > > ddi_periodic_add(9F) returns the non-zero opaque value (ddi_periodic_t), > > > which might be used for ddi_periodic_delete(9F) to specify the request. > > > > > > > Can we not run out of cyclics supporting lots of different > > nanosecond intervals ? Is ddi_periodic_add guaranteed to > > succeed ? > > This might be the implementation, but yes ddi_periodic_add() always succeeds > like timeout(9F). > timeout(9F) doesn't always succeed. it can fail and when it does it panics the system. hopefully this interfaces doesn't behave in the same way. ed From sacadmin Mon Jul 9 14:50:13 2007 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 l69LoCO7012857 for ; Mon, 9 Jul 2007 14:50:12 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l69Lm7je003223; Mon, 9 Jul 2007 22:48:10 +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 <0JKX00J03LW9D400@nwk-avmta-2.sfbay.sun.com>; Mon, 09 Jul 2007 14:48:09 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKX00E3ILW8AY50@nwk-avmta-2.sfbay.sun.com>; Mon, 09 Jul 2007 14:48:08 -0700 (PDT) Received: from localhost (ota.SFBay.Sun.COM [129.146.226.183]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l69Lm8ud291952; Mon, 09 Jul 2007 14:48:08 -0700 (PDT) Date: Mon, 09 Jul 2007 14:48:07 -0700 (PDT) From: eiji.ota@sun.com Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <20070709212117.GD211216@eng.sun.com> Sender: Eiji Ota To: edward.pilatowicz@sun.com Cc: roch.bourbonnais@sun.com, jg@jurassic.sfbay.sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, Dan.Mick@sun.com, pl-direct@sun.com Message-id: <20070709144807G.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.2.0.264296 Lines: 21 References: <18066.15141.854128.479603@gargle.gargle.HOWL> <20070709105458K.eota@sun.com> <20070709212117.GD211216@eng.sun.com> X-Dispatcher: imput version 20000228(IM140) Status: RO Content-Length: 734 Hi, > > > Can we not run out of cyclics supporting lots of different > > > nanosecond intervals ? Is ddi_periodic_add guaranteed to > > > succeed ? > > > > This might be the implementation, but yes ddi_periodic_add() always succeeds > > like timeout(9F). > > > > timeout(9F) doesn't always succeed. it can fail and when it does it > panics the system. hopefully this interfaces doesn't behave in the same > way. I guess you're talking about the implementation of timeout(9F) when you encounter the limit. As the interface, ddi_periodic_add() always returns the meaningful value as timeout(9F) does. About the implementation of ddi_periodic_add(), the way is being considered to avoid the panic as much as possible so far. -Eiji From sacadmin Mon Jul 9 15:04:45 2007 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 l69M4jCB013678 for ; Mon, 9 Jul 2007 15:04:45 -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 l69M2mSs012723; Mon, 9 Jul 2007 15:02:48 -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 <0JKX00509MKNYA00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 09 Jul 2007 15:02:47 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKX00FZXMKMAK80@nwk-avmta-1.sfbay.Sun.COM>; Mon, 09 Jul 2007 15:02:46 -0700 (PDT) Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l69M2jYL013208; Mon, 09 Jul 2007 22:02:45 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JKX00C01LH97R00@mail-amer.sun.com> (original mail from Mark.Johnson@Sun.COM); Mon, 09 Jul 2007 16:02:45 -0600 (MDT) Received: from mrj.local ([75.68.54.173]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JKX00JAJMKJSVS8@mail-amer.sun.com>; Mon, 09 Jul 2007 16:02:45 -0600 (MDT) Date: Mon, 09 Jul 2007 18:04:13 -0400 From: Mark Johnson Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <20070709144807G.eota@sun.com> Sender: Mark.Johnson@sun.com To: Eiji.Ota@sun.com Cc: Edward.Pilatowicz@sun.com, Roch.Bourbonnais@sun.com, jg@jurassic.sfbay.sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, Dan.Mick@sun.com, pl-direct@sun.com Message-id: <4692B0DD.2040607@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <18066.15141.854128.479603@gargle.gargle.HOWL> <20070709105458K.eota@sun.com> <20070709212117.GD211216@eng.sun.com> <20070709144807G.eota@sun.com> User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) Status: RO Content-Length: 1061 Eiji.Ota@Sun.COM wrote: > Hi, > >>>> Can we not run out of cyclics supporting lots of different >>>> nanosecond intervals ? Is ddi_periodic_add guaranteed to >>>> succeed ? >>> This might be the implementation, but yes ddi_periodic_add() always succeeds >>> like timeout(9F). >>> >> timeout(9F) doesn't always succeed. it can fail and when it does it >> panics the system. hopefully this interfaces doesn't behave in the same >> way. > > I guess you're talking about the implementation of timeout(9F) when you > encounter the limit. As the interface, ddi_periodic_add() always returns > the meaningful value as timeout(9F) does. About the implementation of > ddi_periodic_add(), the way is being considered to avoid the panic as > much as possible so far. ddi_periodic_add() will not panic because it is restricted to being called in base context e.g. driver attach function. kmem allocs will always sleep. timeout()'s panic is due to allocs failing due to nosleep. MRJ -- Mark Johnson Sun Microsystems, Inc. (781) 442-0869 From sacadmin Tue Jul 10 06:15:01 2007 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 l6ADF0nD004591 for ; Tue, 10 Jul 2007 06:15:00 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l6ADCv8s022269; Tue, 10 Jul 2007 21:12:58 +0800 (SGT) 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 <0JKY0020BSPK7T00@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Jul 2007 06:12:57 -0700 (PDT) Received: from dm-france-01.uk.sun.com ([129.156.101.188]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKY00C2SSPJ8BE0@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Jul 2007 06:12:56 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by dm-france-01.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l6ADCnEx014803; Tue, 10 Jul 2007 14:12:50 +0100 (BST) Received: from corn.Sun.COM (corn [129.157.192.240]) by bebop.France.Sun.COM (8.13.8+Sun/8.13.8) with SMTP id l6ADCiJk005590; Tue, 10 Jul 2007 15:12:44 +0200 (MEST) Date: Tue, 10 Jul 2007 15:07:11 +0200 From: Roch - PAE Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <20070709105458K.eota@sun.com> To: Eiji.Ota@sun.com Cc: Roch.Bourbonnais@sun.com, jg@jurassic.sfbay.sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, Dan.Mick@sun.com, pl-direct@sun.com Message-id: <18067.33919.823981.538340@gargle.gargle.HOWL> Organization: SUN Microsystems MIME-version: 1.0 X-Mailer: VM 7.19 under 21.1 (patch 3) "Acadia" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200707062150.l66Lowwr770052@jurassic.eng.sun.com> <18066.15141.854128.479603@gargle.gargle.HOWL> <20070709105458K.eota@sun.com> Phone: (+33).4.76.18.83.20 (x[70]38320) Status: RO Content-Length: 4060 Eiji.Ota@Sun.COM writes: > Hi, > > > > o only one callback context > > > > > > timeout(9F) supports only one callback context (kernel context), > > > and if a device driver needs to invoke its callback function in interrupt > > > context (e.g. the real-time application calls the driver routine), > > > timeout(9F) cannot be used for that purpose. (cv_timedwait(9F) should be > > > used instead) > > > > The proposition does not seem to provide callback from a > > real-time non-interrupt context. Maybe the text should > > refrain from using "real-time". > > This is an example here to explain one of restrictions timeout(9F) has, and > the man pages don't use this "real-time" word. > > > > > > > interval: interval time in nanoseconds > > > > > > > Could add text about restrictions on interval (see below). > > I thought NOTES would be a good place where the restriction is described.. > > > > level : callback interrupt level > > > > > > If the value is zero, the callback function is invoked > > > in kernel context. If the value is more than zero, but less > > > than or equal to ten, the callback function is invoked in interrupt > > > context at the specified interrupt level, which may be used for > > > real time applications. > > > > > > This value must be in range of 0-10. > > > > > > DESCRIPTION > > > ddi_periodic_add(9F) schedules the specified function to be > > > periodically invoked in the nanosecond interval time. > > > > > > As well as timeout(9F), the exact time interval over which the function > > > takes effect cannot be guaranteed, but the value given is a close > > > approximation. > > > > > > > > > RETURN VALUES > > > ddi_periodic_add(9F) returns the non-zero opaque value (ddi_periodic_t), > > > which might be used for ddi_periodic_delete(9F) to specify the request. > > > > > > > Can we not run out of cyclics supporting lots of different > > nanosecond intervals ? Is ddi_periodic_add guaranteed to > > succeed ? > > This might be the implementation, but yes ddi_periodic_add() always succeeds > like timeout(9F). > > > > NOTES > > > The actual interval time depends on the clock resolution on the system. > > > The interval less than the clock resolution rounds up to the resolution > > > internally. For example, if the system resolution is 10ms, less than > > > 10ms interval rounds up to 10ms internally. > > > > > > > > > So small requested intervals will be rounded up to the clock > > resolution but larger that clock resolution intervals will > > not be rounded ? A crazy 1 microsecond request will then be > > honored with a callback every 10ms. Correct ? Will a 12ms > > request will be honored with callbacks every 12ms ? > > The resolution here is the system resolution. If you change it to > 1ms (e.g. by setting 1 to hires_tick), then the shortest interval > is 1ms, and your 1 ms request can be taken. If you don't change the > system resolution (i.e. 10ms currently), it rounds up to 10ms. It > explains the shortest interval is the same as the system resolution, > and the interval larger than that is not affected. > > -Eiji So the minimal supported interval is based on the value of the clock resolution but I understand the callbacks are not initiated by the clock. Could we not have a different minimal resolution not linked to clock. Why is there a link made between this interface and the clock resolution ? ____________________________________________________________________________________ Roch Bourbonnais Sun Microsystems, Icnc-Grenoble Senior Performance Analyst 180, Avenue De L'Europe, 38330, Montbonnot Saint Martin, France http://icncweb.france/~rbourbon http://blogs.sun.com/roch Roch.Bourbonnais@Sun.Com (+33).4.76.18.83.20 From sacadmin Tue Jul 10 06:24:11 2007 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 l6ADOBam004747 for ; Tue, 10 Jul 2007 06:24:11 -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 l6ADMFCM007718; Tue, 10 Jul 2007 06:22:15 -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 <0JKY00C0PT539F00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Jul 2007 06:22:15 -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 <0JKY00FG4T52LL80@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Jul 2007 06:22:15 -0700 (PDT) Received: from holland (room101.Holland.Sun.COM [129.159.130.93]) by dm-holland-02.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l6ADM68H014240; Tue, 10 Jul 2007 14:22:06 +0100 (BST) Date: Tue, 10 Jul 2007 15:22:06 +0200 From: Casper.Dik@sun.com Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <18067.33919.823981.538340@gargle.gargle.HOWL> Sender: casper@holland.sun.com To: Roch - PAE Cc: Eiji.Ota@sun.com, jg@jurassic.sfbay.sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, Dan.Mick@sun.com, pl-direct@sun.com Message-id: <200707101322.l6ADM68H014240@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.2.0.264296 References: <200707062150.l66Lowwr770052@jurassic.eng.sun.com> <18066.15141.854128.479603@gargle.gargle.HOWL> <20070709105458K.eota@sun.com> <18067.33919.823981.538340@gargle.gargle.HOWL> Status: RO Content-Length: 1238 >So the minimal supported interval is based on the value of >the clock resolution but I understand the callbacks are not >initiated by the clock. > >Could we not have a different minimal resolution not linked >to clock. Why is there a link made between this interface >and the clock resolution ? This would also support the principle of "least surprise"; a number of kernel drivers, such as the Ultra-45 audio driver, use delay or other "make time pass" functions with some form of drvusectohz() argument. Unfortunately, many of these calls use an argument < 10ms and as such we enter untested territory. (100Hz is tested, 1000Hz is barely tested seeing that it breaks Ultra-45's audio) It seems that we need to support some standard minimum granularity and possible even enforce this on debug kernel. (Similary, drvusectohz should perhaps flag uses where it is called with ridiculous small amounts such as 1ms or possibly 100us or less). I would imagine a device may not be able to deal with getting only one-tenth of the number of callbacks it expects. Similarly, if we make it depend on the clock resolution, a naive driver may get 10 times more than it bargains for when the clock frequency is 10 times higher. Casper From sacadmin Tue Jul 10 10:40:36 2007 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 l6AHeZoP011343 for ; Tue, 10 Jul 2007 10:40:35 -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 l6AHcIEr013815; Wed, 11 Jul 2007 01:38:29 +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 <0JKZ00E09503WW00@brm-avmta-1.central.sun.com>; Tue, 10 Jul 2007 11:38:27 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKZ00CZL501EI30@brm-avmta-1.central.sun.com>; Tue, 10 Jul 2007 11:38:25 -0600 (MDT) Received: from localhost (ota.SFBay.Sun.COM [129.146.226.183]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l6AHcOcX476370; Tue, 10 Jul 2007 10:38:24 -0700 (PDT) Date: Tue, 10 Jul 2007 10:38:24 -0700 (PDT) From: eiji.ota@sun.com Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <18067.33919.823981.538340@gargle.gargle.HOWL> Sender: Eiji Ota To: Roch.Bourbonnais@sun.com Cc: jg@jurassic.sfbay.sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, Dan.Mick@sun.com, pl-direct@sun.com Message-id: <20070710103824C.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.2.0.264296 Lines: 47 References: <18066.15141.854128.479603@gargle.gargle.HOWL> <20070709105458K.eota@sun.com> <18067.33919.823981.538340@gargle.gargle.HOWL> X-Dispatcher: imput version 20000228(IM140) Status: RO Content-Length: 2137 Hi, > > > So small requested intervals will be rounded up to the clock > > > resolution but larger that clock resolution intervals will > > > not be rounded ? A crazy 1 microsecond request will then be > > > honored with a callback every 10ms. Correct ? Will a 12ms > > > request will be honored with callbacks every 12ms ? > > > > The resolution here is the system resolution. If you change it to > > 1ms (e.g. by setting 1 to hires_tick), then the shortest interval > > is 1ms, and your 1 ms request can be taken. If you don't change the > > system resolution (i.e. 10ms currently), it rounds up to 10ms. It > > explains the shortest interval is the same as the system resolution, > > and the interval larger than that is not affected. > > > > -Eiji > > So the minimal supported interval is based on the value of > the clock resolution but I understand the callbacks are not > initiated by the clock. > > Could we not have a different minimal resolution not linked > to clock. Why is there a link made between this interface > and the clock resolution ? The interface uses the cyclic with the finest resolution on the system. As you know, the default resolution is 10000us = 10ms, and that's why the current value is 10ms, but you can change it to 1ms by hires_tick. ADDR LEVL PEND FLAGS FIRE USECINT HANDLER 0000060000a21c28 lock 0 0000 17e4b7eff05c00 10000 clock ^^^^^ ADDR LEVL PEND FLAGS FIRE USECINT HANDLER 0000060000a21c00 high 0 0000 17e4ba0eefed80 10000 cbe_hres_tick ^^^^^ Solaris can have either 1ms or 10ms, but so far the smaller values are not supported. (according to the comment..) * Default hz is 100, but if we set hires_tick we get higher resolution * clock behavior (currently defined to be 1000 hz). Higher values seem * to work, but are not supported. so the interface depends on the cyclic subsystem, and the finest resolution is currently 1ms or 10ms. This value might change in the future though. -Eiji From sacadmin Tue Jul 10 10:45:17 2007 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 l6AHjHiU011543 for ; Tue, 10 Jul 2007 10:45:17 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l6AHgVn2019208; Tue, 10 Jul 2007 11:42:32 -0600 (MDT) 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 <0JKZ00C0D5891100@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Jul 2007 10:43:21 -0700 (PDT) Received: from dm-holland-01.uk.sun.com ([129.156.101.192]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKZ003CM586CD90@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Jul 2007 10:43:18 -0700 (PDT) Received: from holland (room101.Holland.Sun.COM [129.159.130.93]) by dm-holland-01.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l6AHh8iV007467; Tue, 10 Jul 2007 18:43:08 +0100 (BST) Date: Tue, 10 Jul 2007 19:43:08 +0200 From: Casper.Dik@Sun.COM Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <20070710103824C.eota@sun.com> Sender: casper@holland.sun.com To: Eiji.Ota@Sun.COM Cc: Roch.Bourbonnais@Sun.COM, jg@jurassic.sfbay.sun.com, psarc@Sun.COM, Wesley.Shao@Sun.COM, Shidokht.Yadegari@Sun.COM, Bryan.Cantrill@Sun.COM, Sunay.Tripathi@Sun.COM, Dan.Mick@Sun.COM, pl-direct@Sun.COM Message-id: <200707101743.l6AHh8iV007467@dm-holland-01.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <18066.15141.854128.479603@gargle.gargle.HOWL> <20070709105458K.eota@sun.com> <18067.33919.823981.538340@gargle.gargle.HOWL> <20070710103824C.eota@sun.com> Status: RO Content-Length: 415 >so the interface depends on the cyclic subsystem, and the finest resolution >is currently 1ms or 10ms. This value might change in the future though. There's a risk there, though, similar to the delay(drv_usectohz(100)) calls we have in Solaris. How do you propose to prevent breakage in future when the interval becomes (much?) smaller given that we already see breakage now with hires_tick enabled? Casper From sacadmin Tue Jul 10 10:57:51 2007 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 l6AHvpk8013217 for ; Tue, 10 Jul 2007 10:57:51 -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 l6AHtoqA011113; Tue, 10 Jul 2007 10:55:52 -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 <0JKZ00F0L5T2VJ00@brm-avmta-1.central.sun.com>; Tue, 10 Jul 2007 11:55:50 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKZ00C995T1EB60@brm-avmta-1.central.sun.com>; Tue, 10 Jul 2007 11:55:49 -0600 (MDT) Received: from localhost (ota.SFBay.Sun.COM [129.146.226.183]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l6AHtnDS481874; Tue, 10 Jul 2007 10:55:49 -0700 (PDT) Date: Tue, 10 Jul 2007 10:55:48 -0700 (PDT) From: eiji.ota@sun.com Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <200707101743.l6AHh8iV007467@dm-holland-01.uk.sun.com> Sender: Eiji Ota To: Casper.Dik@sun.com Cc: Roch.Bourbonnais@sun.com, jg@jurassic.sfbay.sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, Dan.Mick@sun.com, pl-direct@sun.com Message-id: <20070710105548Q.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.2.0.264296 Lines: 20 References: <18067.33919.823981.538340@gargle.gargle.HOWL> <20070710103824C.eota@sun.com> <200707101743.l6AHh8iV007467@dm-holland-01.uk.sun.com> X-Dispatcher: imput version 20000228(IM140) Status: RO Content-Length: 871 Hi, > >so the interface depends on the cyclic subsystem, and the finest resolution > >is currently 1ms or 10ms. This value might change in the future though. > > There's a risk there, though, similar to the delay(drv_usectohz(100)) > calls we have in Solaris. > > How do you propose to prevent breakage in future when the interval > becomes (much?) smaller given that we already see breakage now with > hires_tick enabled? The interface just uses the system resolution, which is usually 10ms, and can be 1ms by hires_tick, but it doesn't set or change the system resolution by itself. i.e. it uses the acceptable resolution only. If the system resolution can change to a finer one, the interface can use it, but this should be determined differently from the interface, probably after the overall performance is well checked and no degradation is confirmed. -Eiji From sacadmin Tue Jul 10 11:06:05 2007 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 l6AI65Ps013897 for ; Tue, 10 Jul 2007 11:06:05 -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 l6AI46oN013246; Tue, 10 Jul 2007 11:04:09 -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 <0JKZ00E0166W0A00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Jul 2007 11:04:08 -0700 (PDT) Received: from dm-holland-01.uk.sun.com ([129.156.101.192]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKZ003LJ66VCDC0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Jul 2007 11:04:08 -0700 (PDT) Received: from holland (room101.Holland.Sun.COM [129.159.130.93]) by dm-holland-01.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l6AI402O010349; Tue, 10 Jul 2007 19:04:00 +0100 (BST) Date: Tue, 10 Jul 2007 20:04:00 +0200 From: Casper.Dik@sun.com Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <20070710105548Q.eota@sun.com> Sender: casper@holland.sun.com To: Eiji.Ota@sun.com Cc: Roch.Bourbonnais@sun.com, jg@jurassic.sfbay.sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, Dan.Mick@sun.com, pl-direct@sun.com Message-id: <200707101804.l6AI402O010349@dm-holland-01.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <18067.33919.823981.538340@gargle.gargle.HOWL> <20070710103824C.eota@sun.com> <200707101743.l6AHh8iV007467@dm-holland-01.uk.sun.com> <20070710105548Q.eota@sun.com> Status: RO Content-Length: 1017 >Hi, > >> >so the interface depends on the cyclic subsystem, and the finest resolution >> >is currently 1ms or 10ms. This value might change in the future though. >> >> There's a risk there, though, similar to the delay(drv_usectohz(100)) >> calls we have in Solaris. >> >> How do you propose to prevent breakage in future when the interval >> becomes (much?) smaller given that we already see breakage now with >> hires_tick enabled? > >The interface just uses the system resolution, which is usually 10ms, and >can be 1ms by hires_tick, but it doesn't set or change the system resolution >by itself. i.e. it uses the acceptable resolution only. If the system >resolution can change to a finer one, the interface can use it, but this >should be determined differently from the interface, probably after the >overall performance is well checked and no degradation is confirmed. What I really mean is this: will kernels (or DEBUG kernels?) refuse unreasonable periods such as "once every microsecond"? Casper From sacadmin Tue Jul 10 11:16:02 2007 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 l6AIG1Fk014592 for ; Tue, 10 Jul 2007 11:16:01 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l6AIDqeB021044; Tue, 10 Jul 2007 19:13:59 +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 <0JKZ00F056NA9100@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Jul 2007 11:13:58 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKZ00D0M6NAT720@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Jul 2007 11:13:58 -0700 (PDT) Received: from localhost (ota.SFBay.Sun.COM [129.146.226.183]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l6AIDwCA487315; Tue, 10 Jul 2007 11:13:58 -0700 (PDT) Date: Tue, 10 Jul 2007 11:13:57 -0700 (PDT) From: eiji.ota@sun.com Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <200707101804.l6AI402O010349@dm-holland-01.uk.sun.com> Sender: Eiji Ota To: Casper.Dik@sun.com Cc: Roch.Bourbonnais@sun.com, jg@jurassic.sfbay.sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, Dan.Mick@sun.com, pl-direct@sun.com Message-id: <20070710111357N.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.2.0.264296 Lines: 11 References: <200707101743.l6AHh8iV007467@dm-holland-01.uk.sun.com> <20070710105548Q.eota@sun.com> <200707101804.l6AI402O010349@dm-holland-01.uk.sun.com> X-Dispatcher: imput version 20000228(IM140) Status: RO Content-Length: 428 > > What I really mean is this: will kernels (or DEBUG kernels?) refuse > unreasonable periods such as "once every microsecond"? > I'm not sure if I can take your question correctly, but the interface rounds up a smaller interval to the system resolution if it's passed. (so it cannot accept it) If you talk about the cyclic subsystem, well I'm sorry, but it would be beyond the interface.. (so I cannot answer it...) -Eiji From sacadmin Tue Jul 10 11:23:49 2007 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 l6AINme9015057 for ; Tue, 10 Jul 2007 11:23: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 l6AILXvU026907; Wed, 11 Jul 2007 02:21:47 +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 <0JKZ00F01708O900@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Jul 2007 11:21:44 -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 <0JKZ003AC707CDE0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Jul 2007 11:21:44 -0700 (PDT) Received: from holland (room101.Holland.Sun.COM [129.159.130.93]) by dm-holland-02.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l6AILajJ009874; Tue, 10 Jul 2007 19:21:36 +0100 (BST) Date: Tue, 10 Jul 2007 20:21:35 +0200 From: Casper.Dik@sun.com Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <20070710111357N.eota@sun.com> Sender: casper@holland.sun.com To: Eiji.Ota@sun.com Cc: Roch.Bourbonnais@sun.com, jg@jurassic.sfbay.sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, Dan.Mick@sun.com, pl-direct@sun.com Message-id: <200707101821.l6AILajJ009874@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.2.0.264296 References: <200707101743.l6AHh8iV007467@dm-holland-01.uk.sun.com> <20070710105548Q.eota@sun.com> <200707101804.l6AI402O010349@dm-holland-01.uk.sun.com> <20070710111357N.eota@sun.com> Status: RO Content-Length: 1130 >> >> What I really mean is this: will kernels (or DEBUG kernels?) refuse >> unreasonable periods such as "once every microsecond"? >> > >I'm not sure if I can take your question correctly, but the interface rounds >up a smaller interval to the system resolution if it's passed. (so it cannot >accept it) If you talk about the cyclic subsystem, well I'm sorry, but it >would be beyond the interface.. (so I cannot answer it...) Let me try and explain this another way: If I select a period of 1 nanosecond I get 1/Hz seconds, right? (So either 10ms or 1ms) You get either 100 or a 1000 calls per second Now suppose we get to a system were arbitrary timers are easy to create (say a "tickless kernel") and we can start issuing 10us timers. The same interval now gets you 100,000 calls per second. This is very questionable, I think (we see the same problem now in some cases). I'd prefer a DEBUG kernel to panic if confronted with an interval shorter than the minimum now supported unless you can make a case why we should allow people to specify shorter intervals even if they have no way to test them. Casper From sacadmin Tue Jul 10 11:26:06 2007 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 l6AIQ6JX015166 for ; Tue, 10 Jul 2007 11:26:06 -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 l6AIO7kw017491; Tue, 10 Jul 2007 11:24:08 -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 <0JKZ00F2J747VD00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Jul 2007 11:24:07 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.17.57]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKZ003M3747CDE0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Jul 2007 11:24:07 -0700 (PDT) Received: from tethys (tethys.SFBay.Sun.COM [129.146.226.92]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id l6AIO691177278; Tue, 10 Jul 2007 11:24:06 -0700 (PDT) Date: Tue, 10 Jul 2007 11:23:08 -0700 (PDT) From: Jerry Gilliam Subject: Re: 2007/402: Driver Periodic Timeouts To: Casper.Dik@sun.com, Eiji.Ota@sun.com Cc: Roch.Bourbonnais@sun.com, jg@jurassic.sfbay.sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, Dan.Mick@sun.com, pl-direct@sun.com Reply-to: Jerry Gilliam Message-id: <200707101824.l6AIO691177278@jurassic.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_64 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: VRmV8q4mxKfcyWU3FiDB/w== X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 472 > >There's a risk there, though, similar to the delay(drv_usectohz(100)) >calls we have in Solaris. > >How do you propose to prevent breakage in future when the interval >becomes (much?) smaller given that we already see breakage now with >hires_tick enabled? > >Casper > What I'd suggest is keeping this interface with the existing semantics and limitations functioning as is, and introducing a new set of interfaces together with more flexible interval specs. -jg From sacadmin Tue Jul 10 11:31:21 2007 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 l6AIVK1K015424 for ; Tue, 10 Jul 2007 11:31:21 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l6AITCdi025089; Tue, 10 Jul 2007 19:29:18 +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 <0JKZ00G0F7CSDE00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Jul 2007 11:29:16 -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 <0JKZ0039A7CSCDF0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Jul 2007 11:29:16 -0700 (PDT) Received: from localhost (ota.SFBay.Sun.COM [129.146.226.183]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l6AITGOU491049; Tue, 10 Jul 2007 11:29:16 -0700 (PDT) Date: Tue, 10 Jul 2007 11:29:15 -0700 (PDT) From: Eiji.Ota@sun.com Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <200707101821.l6AILajJ009874@dm-holland-02.uk.sun.com> Sender: Eiji Ota To: Casper.Dik@sun.com Cc: Roch.Bourbonnais@sun.com, jg@jurassic.sfbay.sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, Dan.Mick@sun.com, pl-direct@sun.com Message-id: <20070710112915N.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.2.0.264296 Lines: 41 References: <200707101804.l6AI402O010349@dm-holland-01.uk.sun.com> <20070710111357N.eota@sun.com> <200707101821.l6AILajJ009874@dm-holland-02.uk.sun.com> X-Dispatcher: imput version 20000228(IM140) Status: RO Content-Length: 1407 Hi Casper, Thank you for your detailed explanation. It seems I misunderstood your previous question. If you don't mind, may I keep discussing this off-line? It seems related to the implementation also. Cheers, -Eiji > >> What I really mean is this: will kernels (or DEBUG kernels?) refuse > >> unreasonable periods such as "once every microsecond"? > >> > > > >I'm not sure if I can take your question correctly, but the interface rounds > >up a smaller interval to the system resolution if it's passed. (so it cannot > >accept it) If you talk about the cyclic subsystem, well I'm sorry, but it > >would be beyond the interface.. (so I cannot answer it...) > > > Let me try and explain this another way: > > If I select a period of 1 nanosecond I get 1/Hz seconds, right? > (So either 10ms or 1ms) You get either 100 or a 1000 calls per > second > > Now suppose we get to a system were arbitrary timers are easy to create > (say a "tickless kernel") and we can start issuing 10us timers. > > The same interval now gets you 100,000 calls per second. > > > This is very questionable, I think (we see the same problem now in some > cases). > > I'd prefer a DEBUG kernel to panic if confronted with an interval shorter > than the minimum now supported unless you can make a case why we should > allow people to specify shorter intervals even if they have no way > to test them. > > Casper From sacadmin Tue Jul 10 11:36:41 2007 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 l6AIafVF015630 for ; Tue, 10 Jul 2007 11:36:41 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l6AIYWcn026628; Tue, 10 Jul 2007 19:34:42 +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 <0JKZ00G0F7LTUK00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Jul 2007 11:34:41 -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 <0JKZ003LE7LSCAE0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Jul 2007 11:34:40 -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 l6AIYe2D025999; Tue, 10 Jul 2007 11:34:40 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JKZ001017AEHN00@fe-sfbay-10.sun.com> (original mail from Garrett.Damore@Sun.COM); Tue, 10 Jul 2007 11:34:40 -0700 (PDT) Received: from [192.168.251.21] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JKZ0076Z7LQD5A0@fe-sfbay-10.sun.com>; Tue, 10 Jul 2007 11:34:39 -0700 (PDT) Date: Tue, 10 Jul 2007 11:31:42 -0700 From: "Garrett D'Amore" Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <200707101821.l6AILajJ009874@dm-holland-02.uk.sun.com> Sender: Garrett.Damore@sun.com To: Casper.Dik@sun.com Cc: Eiji.Ota@sun.com, Roch.Bourbonnais@sun.com, jg@jurassic.sfbay.sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, Dan.Mick@sun.com, pl-direct@sun.com Message-id: <4693D08E.5000708@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200707101743.l6AHh8iV007467@dm-holland-01.uk.sun.com> <20070710105548Q.eota@sun.com> <200707101804.l6AI402O010349@dm-holland-01.uk.sun.com> <20070710111357N.eota@sun.com> <200707101821.l6AILajJ009874@dm-holland-02.uk.sun.com> User-Agent: Thunderbird 2.0.0.0 (X11/20070605) Status: RO Content-Length: 1922 Casper.Dik@Sun.COM wrote: >>> What I really mean is this: will kernels (or DEBUG kernels?) refuse >>> unreasonable periods such as "once every microsecond"? >>> >>> >> I'm not sure if I can take your question correctly, but the interface rounds >> up a smaller interval to the system resolution if it's passed. (so it cannot >> accept it) If you talk about the cyclic subsystem, well I'm sorry, but it >> would be beyond the interface.. (so I cannot answer it...) >> > > > Let me try and explain this another way: > > If I select a period of 1 nanosecond I get 1/Hz seconds, right? > (So either 10ms or 1ms) You get either 100 or a 1000 calls per > second > > Now suppose we get to a system were arbitrary timers are easy to create > (say a "tickless kernel") and we can start issuing 10us timers. > > The same interval now gets you 100,000 calls per second. > > > This is very questionable, I think (we see the same problem now in some > cases). > > I'd prefer a DEBUG kernel to panic if confronted with an interval shorter > than the minimum now supported unless you can make a case why we should > allow people to specify shorter intervals even if they have no way > to test them. > There are devices which need to be tickled *no more frequently* than a set time frame. A common paradigm is to use drv_usectohz() then cv_timedwait. You might do this for a device which really only needs a 10mesc (or even 1msec) delay.... because you don't want to spin for that time and you can block. So drv_usectohz() isn't the place to flag this, I think. Maybe the new cyclic subsystem should flag it though. I'm not sure about other uses. It sure would be nice to be able to set timer interrupts that can occur on shorter boundaries than clock ticks though. Fortunately most of the devices that I've run across that need this also have a general purpose timer on the device. -- Garrett From sacadmin Tue Jul 10 11:37:23 2007 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 l6AIbMND015644 for ; Tue, 10 Jul 2007 11:37:22 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l6AIZLtL026853; Tue, 10 Jul 2007 19:35:24 +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 <0JKZ00I717MX0800@brm-avmta-1.central.sun.com>; Tue, 10 Jul 2007 12:35:21 -0600 (MDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKZ00CXB7MWEB80@brm-avmta-1.central.sun.com>; Tue, 10 Jul 2007 12:35:20 -0600 (MDT) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l6AIZIvc028326; Tue, 10 Jul 2007 11:35:18 -0700 (PDT) Received: from [129.146.108.62] (vinifera.SFBay.Sun.COM [129.146.108.62]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id l6AIZHE10871; Tue, 10 Jul 2007 11:35:17 -0700 (PDT) Date: Tue, 10 Jul 2007 11:35:16 -0700 From: Scott Rotondo Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <200707101824.l6AIO691177278@jurassic.eng.sun.com> To: Jerry Gilliam Cc: Casper.Dik@sun.com, Eiji.Ota@sun.com, Roch.Bourbonnais@sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, Dan.Mick@sun.com, pl-direct@sun.com Message-id: <4693D164.5040405@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200707101824.l6AIO691177278@jurassic.eng.sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070326) Status: RO Content-Length: 678 Jerry Gilliam wrote: >> There's a risk there, though, similar to the delay(drv_usectohz(100)) >> calls we have in Solaris. >> >> How do you propose to prevent breakage in future when the interval >> becomes (much?) smaller given that we already see breakage now with >> hires_tick enabled? >> >> Casper >> > > > What I'd suggest is keeping this interface with the existing > semantics and limitations functioning as is, and introducing > a new set of interfaces together with more flexible interval > specs. > But that wouldn't accomplish what Casper was suggesting, which is to catch uses of the existing interface that supply unreasonably small argument values. Scott From sacadmin Tue Jul 10 11:49:43 2007 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 l6AInghs015914 for ; Tue, 10 Jul 2007 11:49:43 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l6AIlg44000145; Tue, 10 Jul 2007 19:47:43 +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 <0JKZ00I0P87HSR00@brm-avmta-1.central.sun.com>; Tue, 10 Jul 2007 12:47:41 -0600 (MDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKZ00CD987FEE70@brm-avmta-1.central.sun.com>; Tue, 10 Jul 2007 12:47:40 -0600 (MDT) Received: from holland (room101.Holland.Sun.COM [129.159.130.93]) by dm-holland-02.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l6AIlVJp012803; Tue, 10 Jul 2007 19:47:31 +0100 (BST) Date: Tue, 10 Jul 2007 20:47:31 +0200 From: Casper.Dik@sun.com Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <4693D08E.5000708@sun.com> Sender: casper@holland.sun.com To: "Garrett D'Amore" Cc: Eiji.Ota@sun.com, Roch.Bourbonnais@sun.com, jg@jurassic.sfbay.sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, Dan.Mick@sun.com, pl-direct@sun.com Message-id: <200707101847.l6AIlVJp012803@dm-holland-02.uk.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200707101743.l6AHh8iV007467@dm-holland-01.uk.sun.com> <20070710105548Q.eota@sun.com> <200707101804.l6AI402O010349@dm-holland-01.uk.sun.com> <20070710111357N.eota@sun.com> <200707101821.l6AILajJ009874@dm-holland-02.uk.sun.com> <4693D08E.5000708@sun.com> Status: RO Content-Length: 1469 >There are devices which need to be tickled *no more frequently* than a >set time frame. A common paradigm is to use drv_usectohz() then >cv_timedwait. You might do this for a device which really only needs a >10mesc (or even 1msec) delay.... because you don't want to spin for that >time and you can block. > >So drv_usectohz() isn't the place to flag this, I think. That would be difficult. OTOH, detecting such sillyness in ON is perhaps correct. (If a driver waits for drv_usectohz(100) before the device is "settled" then it will wait a different interval on a 100Hz kernel than a 1000Hz kernel; this may be fine, but there are known instances where this is wrong; and certainly it is untested) >Maybe the new cyclic subsystem should flag it though. > >I'm not sure about other uses. > >It sure would be nice to be able to set timer interrupts that can occur >on shorter boundaries than clock ticks though. Fortunately most of the >devices that I've run across that need this also have a general purpose >timer on the device. A "Clockless" kernel would be really nice. One thing that trips up many people is the fact that poll(2) is *required* to round up to *two* clockticks. And that often means 20ms as minimum sleep time. If you can just schedule exactly 10ms in future than that would be so much better (or 1ms) Such a timeout mechanism would be immensely practical for most of Solaris and would give an overal smoother experience. Casper From sacadmin Tue Jul 10 12:11:47 2007 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 l6AJBkXh017610 for ; Tue, 10 Jul 2007 12:11:46 -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 l6AJ9ZN9011374; Wed, 11 Jul 2007 03:09:38 +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 <0JKZ00K0197Z4Q00@brm-avmta-1.central.sun.com>; Tue, 10 Jul 2007 13:09:36 -0600 (MDT) Received: from jurassic.eng.sun.com ([129.146.58.37]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKZ00CW297YEFB0@brm-avmta-1.central.sun.com>; Tue, 10 Jul 2007 13:09:35 -0600 (MDT) Received: from tethys (tethys.SFBay.Sun.COM [129.146.226.92]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id l6AJ9YbT178984; Tue, 10 Jul 2007 12:09:34 -0700 (PDT) Date: Tue, 10 Jul 2007 12:08:35 -0700 (PDT) From: Jerry Gilliam Subject: Re: 2007/402: Driver Periodic Timeouts To: scott.rotondo@sun.com Cc: Casper.Dik@sun.com, Eiji.Ota@sun.com, Roch.Bourbonnais@sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, Dan.Mick@sun.com, pl-direct@sun.com Reply-to: Jerry Gilliam Message-id: <200707101909.l6AJ9YbT178984@jurassic.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_64 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: aECquL120SRYmPUiCew4dA== X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 511 >> >> What I'd suggest is keeping this interface with the existing >> semantics and limitations functioning as is, and introducing >> a new set of interfaces together with more flexible interval >> specs. >> > >But that wouldn't accomplish what Casper was suggesting, which is to >catch uses of the existing interface that supply unreasonably small >argument values. > > Scott Yes, but it would be an option if we don't build in restrictions against the acceptable interval limits to begin with. -jg From sacadmin Tue Jul 10 14:45:29 2007 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 l6ALjSNZ024892 for ; Tue, 10 Jul 2007 14:45:28 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l6ALhKe2021519; Wed, 11 Jul 2007 05:43:27 +0800 (SGT) 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 <0JKZ00103GCEQP00@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Jul 2007 14:43:26 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKZ00DZSGCCSWE0@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Jul 2007 14:43:26 -0700 (PDT) Received: from d1-emea-10.sun.com ([192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6ALhO6N009597; Tue, 10 Jul 2007 21:43:24 +0000 (GMT) Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JKZ00J01G3W8L00@d1-emea-10.sun.com> (original mail from Roch.Bourbonnais@Sun.COM); Tue, 10 Jul 2007 22:43:24 +0100 (BST) Received: from [192.168.1.2] ([86.211.139.25]) by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JKZ00HAXGCAZ1CX@d1-emea-10.sun.com>; Tue, 10 Jul 2007 22:43:24 +0100 (BST) Date: Tue, 10 Jul 2007 23:44:29 +0200 From: Roch Bourbonnais Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <20070710103824C.eota@sun.com> Sender: roch.bourbonnais@sun.com To: Eiji.Ota@sun.com Cc: jg@jurassic.sfbay.sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, Dan.Mick@sun.com, pl-direct@sun.com Message-id: <84A04DB1-94E1-4F18-BB5C-AE30E78400E2@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) Content-type: text/plain; format=flowed; delsp=yes; charset=ISO-8859-1 X-PMX-Version: 5.2.0.264296 References: <18066.15141.854128.479603@gargle.gargle.HOWL> <20070709105458K.eota@sun.com> <18067.33919.823981.538340@gargle.gargle.HOWL> <20070710103824C.eota@sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by sac.sfbay.sun.com id l6ALjTNa024893 Status: RO Content-Length: 2710 Le 10 juil. 07 à 19:38, Eiji.Ota@Sun.COM a écrit : > Hi, > >>>> So small requested intervals will be rounded up to the clock >>>> resolution but larger that clock resolution intervals will >>>> not be rounded ? A crazy 1 microsecond request will then be >>>> honored with a callback every 10ms. Correct ? Will a 12ms >>>> request will be honored with callbacks every 12ms ? >>> >>> The resolution here is the system resolution. If you change it to >>> 1ms (e.g. by setting 1 to hires_tick), then the shortest interval >>> is 1ms, and your 1 ms request can be taken. If you don't change the >>> system resolution (i.e. 10ms currently), it rounds up to 10ms. It >>> explains the shortest interval is the same as the system resolution, >>> and the interval larger than that is not affected. >>> >>> -Eiji >> >> So the minimal supported interval is based on the value of >> the clock resolution but I understand the callbacks are not >> initiated by the clock. >> >> Could we not have a different minimal resolution not linked >> to clock. Why is there a link made between this interface >> and the clock resolution ? > > The interface uses the cyclic with the finest resolution on the > system. As you know, the default resolution is 10000us = 10ms, > and that's why the current value is 10ms, but you can change it to > 1ms by hires_tick. > > ADDR LEVL PEND FLAGS FIRE USECINT HANDLER > 0000060000a21c28 lock 0 0000 17e4b7eff05c00 10000 clock > ^^^^^ > ADDR LEVL PEND FLAGS FIRE USECINT HANDLER > 0000060000a21c00 high 0 0000 17e4ba0eefed80 10000 > cbe_hres_tick > ^^^^^ > Solaris can have either 1ms or 10ms, but so far the smaller values > are not supported. (according to the comment..) > > * Default hz is 100, but if we set hires_tick we get higher > resolution > * clock behavior (currently defined to be 1000 hz). Higher values > seem > * to work, but are not supported. > > so the interface depends on the cyclic subsystem, and the finest > resolution > is currently 1ms or 10ms. This value might change in the future > though. > > -Eiji I am confused about whether the interface provides clock based recurring timeouts or arbitrary intervals. Are the callbacks in sync with the system clock then ? I understand the need to impose a minimum interval to avoid system overload. If the project proposes arbitrary interval recurring callbacks, I don't understand the link made between that minimum interval and the system clock; it seems that another value could be used if we wanted to. -r From sacadmin Tue Jul 10 15:01:26 2007 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 l6AM1Qg6026276 for ; Tue, 10 Jul 2007 15:01:26 -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 l6ALwdbR062494; Tue, 10 Jul 2007 15:58:39 -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 <0JKZ00205H34IL00@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Jul 2007 14:59:28 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKZ00DBWH34SYF0@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Jul 2007 14:59:28 -0700 (PDT) Received: from localhost (ota.SFBay.Sun.COM [129.146.226.183]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l6ALxOUK614296; Tue, 10 Jul 2007 14:59:24 -0700 (PDT) Date: Tue, 10 Jul 2007 14:59:24 -0700 (PDT) From: eiji.ota@sun.com Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <84A04DB1-94E1-4F18-BB5C-AE30E78400E2@Sun.COM> Sender: Eiji Ota To: roch.bourbonnais@sun.com Cc: jg@jurassic.sfbay.sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, Dan.Mick@sun.com, pl-direct@sun.com Message-id: <20070710145924Y.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.2.0.264296 Lines: 73 References: <18067.33919.823981.538340@gargle.gargle.HOWL> <20070710103824C.eota@sun.com> <84A04DB1-94E1-4F18-BB5C-AE30E78400E2@Sun.COM> X-Dispatcher: imput version 20000228(IM140) Status: RO Content-Length: 2981 Hi, > > > >>>> So small requested intervals will be rounded up to the clock > >>>> resolution but larger that clock resolution intervals will > >>>> not be rounded ? A crazy 1 microsecond request will then be > >>>> honored with a callback every 10ms. Correct ? Will a 12ms > >>>> request will be honored with callbacks every 12ms ? > >>> > >>> The resolution here is the system resolution. If you change it to > >>> 1ms (e.g. by setting 1 to hires_tick), then the shortest interval > >>> is 1ms, and your 1 ms request can be taken. If you don't change the > >>> system resolution (i.e. 10ms currently), it rounds up to 10ms. It > >>> explains the shortest interval is the same as the system resolution, > >>> and the interval larger than that is not affected. > >>> > >>> -Eiji > >> > >> So the minimal supported interval is based on the value of > >> the clock resolution but I understand the callbacks are not > >> initiated by the clock. > >> > >> Could we not have a different minimal resolution not linked > >> to clock. Why is there a link made between this interface > >> and the clock resolution ? > > > > The interface uses the cyclic with the finest resolution on the > > system. As you know, the default resolution is 10000us = 10ms, > > and that's why the current value is 10ms, but you can change it to > > 1ms by hires_tick. > > > > ADDR LEVL PEND FLAGS FIRE USECINT HANDLER > > 0000060000a21c28 lock 0 0000 17e4b7eff05c00 10000 clock > > ^^^^^ > > ADDR LEVL PEND FLAGS FIRE USECINT HANDLER > > 0000060000a21c00 high 0 0000 17e4ba0eefed80 10000 > > cbe_hres_tick > > ^^^^^ > > Solaris can have either 1ms or 10ms, but so far the smaller values > > are not supported. (according to the comment..) > > > > * Default hz is 100, but if we set hires_tick we get higher > > resolution > > * clock behavior (currently defined to be 1000 hz). Higher values > > seem > > * to work, but are not supported. > > > > so the interface depends on the cyclic subsystem, and the finest > > resolution > > is currently 1ms or 10ms. This value might change in the future > > though. > > > > -Eiji > > > I am confused about whether the interface provides clock based > recurring timeouts > or arbitrary intervals. Are the callbacks in sync with the system > clock then ? > > I understand the need to impose a minimum interval to avoid system > overload. > If the project proposes arbitrary interval recurring callbacks, I > don't understand > the link made between that minimum interval and the system clock; > it seems that another > value could be used if we wanted to. The clock resolution can change, for example currently you can change it to 1ms or 10ms. In the future it might change to another. Also Solaris uses hrtime now. It uses the hrtime as an argument. -Eiji From sacadmin Tue Jul 10 15:15:10 2007 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 l6AMF9uC027125 for ; Tue, 10 Jul 2007 15:15:09 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l6AMCui1029305; Wed, 11 Jul 2007 06:13:08 +0800 (SGT) 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 <0JKZ00309HPPBG00@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Jul 2007 15:13:01 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKZ00DO7HPOT5D0@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Jul 2007 15:13:00 -0700 (PDT) Received: from d1-emea-10.sun.com ([192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6AMCxmw010320; Tue, 10 Jul 2007 22:12:59 +0000 (GMT) Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JKZ00501HN77C00@d1-emea-10.sun.com> (original mail from Roch.Bourbonnais@Sun.COM); Tue, 10 Jul 2007 23:12:59 +0100 (BST) Received: from [192.168.1.2] ([86.211.139.25]) by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JKZ00HYVHPLZ1FX@d1-emea-10.sun.com>; Tue, 10 Jul 2007 23:12:59 +0100 (BST) Date: Wed, 11 Jul 2007 00:14:19 +0200 From: Roch Bourbonnais Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <20070710145924Y.eota@sun.com> Sender: Roch.Bourbonnais@sun.com To: Eiji.Ota@sun.com Cc: jg@jurassic.sfbay.sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, Dan.Mick@sun.com, pl-direct@sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) Content-type: multipart/alternative; boundary="Boundary_(ID_3GFdK+skUaPguBDL0XtMww)" X-PMX-Version: 5.2.0.264296 References: <18067.33919.823981.538340@gargle.gargle.HOWL> <20070710103824C.eota@sun.com> <84A04DB1-94E1-4F18-BB5C-AE30E78400E2@Sun.COM> <20070710145924Y.eota@sun.com> Status: RO Content-Length: 5892 --Boundary_(ID_3GFdK+skUaPguBDL0XtMww) Content-type: text/plain; format=flowed; delsp=yes; charset=ISO-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE Le 10 juil. 07 =E0 23:59, Eiji.Ota@Sun.COM a =E9crit : >> >> I am confused about whether the interface provides clock based >> recurring timeouts >> or arbitrary intervals. Are the callbacks in sync with the system >> clock then ? >> So are they ? >> I understand the need to impose a minimum interval to avoid system >> overload. >> If the project proposes arbitrary interval recurring callbacks, I >> don't understand >> the link made between that minimum interval and the system clock= ; >> it seems that another >> value could be used if we wanted to. > > The clock resolution can change, for example currently you can = =20 > change it > to 1ms or 10ms. In the future it might change to another. Also Sola= ris > uses hrtime now. It uses the hrtime as an argument. > The project proposes that if the requested interval is less than X, = =20 we use X as the interval. Let's set aside objections to that for now. The project proposes that X be the same as the system clock interval.= =20 Why ? > -Eiji --Boundary_(ID_3GFdK+skUaPguBDL0XtMww) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE
Le 10 juil. 07 = =E0 23:59, Eiji.Ota@Sun.COM a= =E9crit :


=

I am confused about whe= ther the interface provides clock based =A0

recurring timeouts

or arbitrary intervals. Are the callbacks in sync with= the system =A0

clock then ?<= /P>



So are they=A0 ?

I = understand the need to impose a minimum interval to avoid system =A0

overload.

If the project proposes arbitrary inte= rval recurring callbacks,=A0 I =A0

don't understand

the link made betwee= n that=A0 minimum interv= al=A0 and the system clo= ck; =A0

it seems that another=

value could be use= d if we wanted to.


The clock resolution = can change, for example currently you can change it

to 1ms or 10ms. In the future= it might change to another. Also Solaris

uses hrtime now. It uses the hrtime as a= n argument.



The pr= oject proposes that if the requested interval is less than X, we use = X as the interval.
Let's set aside objections to that for n= ow.
The project proposes that X be the same as the system c= lock interval. Why ?

=


-Eiji


--Boundary_(ID_3GFdK+skUaPguBDL0XtMww)-- From sacadmin Tue Jul 10 15:17:30 2007 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 l6AMHT8h027217 for ; Tue, 10 Jul 2007 15:17:30 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l6AMFNVR023403; Tue, 10 Jul 2007 23:15:28 +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 <0JKZ00F01HTPJB00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Jul 2007 15:15:25 -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 <0JKZ003RYHTOF350@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Jul 2007 15:15:25 -0700 (PDT) Received: from localhost (ota.SFBay.Sun.COM [129.146.226.183]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l6AMFOJS619589; Tue, 10 Jul 2007 15:15:24 -0700 (PDT) Date: Tue, 10 Jul 2007 15:15:23 -0700 (PDT) From: eiji.ota@sun.com Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: Sender: Eiji Ota To: Roch.Bourbonnais@sun.com Cc: jg@jurassic.sfbay.sun.com, psarc@sun.com, Wesley.Shao@sun.com, shidokht.yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, Dan.Mick@sun.com, pl-direct@sun.com Message-id: <20070710151523Z.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.2.0.264296 Lines: 32 References: <84A04DB1-94E1-4F18-BB5C-AE30E78400E2@Sun.COM> <20070710145924Y.eota@sun.com> X-Dispatcher: imput version 20000228(IM140) Status: RO Content-Length: 1038 > >> > >> I am confused about whether the interface provides clock based > >> recurring timeouts > >> or arbitrary intervals. Are the callbacks in sync with the system > >> clock then ? > >> > > So are they ? > > >> I understand the need to impose a minimum interval to avoid system > >> overload. > >> If the project proposes arbitrary interval recurring callbacks, I > >> don't understand > >> the link made between that minimum interval and the system clock; > >> it seems that another > >> value could be used if we wanted to. > > > > The clock resolution can change, for example currently you can > > change it > > to 1ms or 10ms. In the future it might change to another. Also Solaris > > uses hrtime now. It uses the hrtime as an argument. > > > > The project proposes that if the requested interval is less than X, > we use X as the interval. > Let's set aside objections to that for now. > The project proposes that X be the same as the system clock interval. > Why ? Because this is the finest resolution.. -Eiji From sacadmin Tue Jul 10 15:47:20 2007 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 l6AMlKxA028971 for ; Tue, 10 Jul 2007 15:47:20 -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 l6AMjNVn003520; Tue, 10 Jul 2007 15:45:23 -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 <0JKZ00407J7NHD00@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Jul 2007 15:45:23 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKZ003A9J7MXE60@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Jul 2007 15:45:23 -0700 (PDT) Received: from [10.1.48.172] (dmick1.West.Sun.COM [10.1.48.172]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l6AMjMV3629585; Tue, 10 Jul 2007 15:45:22 -0700 (PDT) Date: Tue, 10 Jul 2007 15:44:55 -0700 From: Dan Mick Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <20070710151523Z.eota@sun.com> To: eiji.ota@sun.com Cc: Roch.Bourbonnais@sun.com, jg@jurassic.sfbay.sun.com, psarc@sun.com, Wesley.Shao@sun.com, shidokht.yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, pl-direct@sun.com Message-id: <46940BE7.60107@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <84A04DB1-94E1-4F18-BB5C-AE30E78400E2@Sun.COM> <20070710145924Y.eota@sun.com> <20070710151523Z.eota@sun.com> User-Agent: Thunderbird 2.0.0.0 (X11/20070419) Status: RO Content-Length: 314 eiji.ota@sun.com wrote: >> The project proposes that X be the same as the system clock interval. >> Why ? > > Because this is the finest resolution.. Because the project doesn't want to, at this point, create its own cyclics to provide the service, but rather uses the clock cyclic to back-end the service. From sacadmin Tue Jul 10 16:03:24 2007 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 l6AN3Out029593 for ; Tue, 10 Jul 2007 16:03:24 -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 l6AN1Nuk006322; Tue, 10 Jul 2007 16:01:25 -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 <0JKZ0050DJY99G00@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Jul 2007 16:01:21 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKZ0033MJY8XEB0@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Jul 2007 16:01:20 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l6AMxx0Y015565; Tue, 10 Jul 2007 17:59:59 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l6AMxxf8015564; Tue, 10 Jul 2007 17:59:59 -0500 (CDT) Date: Tue, 10 Jul 2007 17:59:59 -0500 From: Nicolas Williams Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <4693D164.5040405@sun.com> To: Scott Rotondo Cc: Jerry Gilliam , Casper.Dik@sun.com, Eiji.Ota@sun.com, Roch.Bourbonnais@sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, Dan.Mick@sun.com, pl-direct@sun.com Message-id: <20070710225958.GZ14352@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200707101824.l6AIO691177278@jurassic.eng.sun.com> <4693D164.5040405@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: 601 On Tue, Jul 10, 2007 at 11:35:16AM -0700, Scott Rotondo wrote: > Jerry Gilliam wrote: > >What I'd suggest is keeping this interface with the existing > >semantics and limitations functioning as is, and introducing > >a new set of interfaces together with more flexible interval > >specs. > > But that wouldn't accomplish what Casper was suggesting, which is to > catch uses of the existing interface that supply unreasonably small > argument values. Wouldn't it suffice to add a way to query the current timeout resolution supported? (and require that this not change until next boot?) Nico -- From sacadmin Tue Jul 10 16:22:29 2007 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 l6ANMTsW000673 for ; Tue, 10 Jul 2007 16:22:29 -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 l6ANJSZ7008841; Tue, 10 Jul 2007 17:19:29 -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 <0JKZ0060DKTUDC00@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Jul 2007 16:20:18 -0700 (PDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKZ006G9KTT6J00@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Jul 2007 16:20:17 -0700 (PDT) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l6ANKFl7007470; Tue, 10 Jul 2007 16:20:15 -0700 (PDT) Received: from [129.146.108.62] (vinifera.SFBay.Sun.COM [129.146.108.62]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id l6ANKEE13672; Tue, 10 Jul 2007 16:20:15 -0700 (PDT) Date: Tue, 10 Jul 2007 16:20:14 -0700 From: Scott Rotondo Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <20070710225958.GZ14352@Sun.COM> To: Nicolas Williams Cc: Jerry Gilliam , Casper.Dik@sun.com, Eiji.Ota@sun.com, Roch.Bourbonnais@sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, Dan.Mick@sun.com, pl-direct@sun.com Message-id: <4694142E.8070706@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200707101824.l6AIO691177278@jurassic.eng.sun.com> <4693D164.5040405@sun.com> <20070710225958.GZ14352@Sun.COM> User-Agent: Thunderbird 2.0b2 (X11/20070326) Status: RO Content-Length: 821 Nicolas Williams wrote: > On Tue, Jul 10, 2007 at 11:35:16AM -0700, Scott Rotondo wrote: >> Jerry Gilliam wrote: >>> What I'd suggest is keeping this interface with the existing >>> semantics and limitations functioning as is, and introducing >>> a new set of interfaces together with more flexible interval >>> specs. >> But that wouldn't accomplish what Casper was suggesting, which is to >> catch uses of the existing interface that supply unreasonably small >> argument values. > > Wouldn't it suffice to add a way to query the current timeout resolution > supported? (and require that this not change until next boot?) > > Nico That would work for newly-written code that uses the new query interface, but it wouldn't help with existing code that makes unwarranted assumptions about the clock rate. Scott From sacadmin Wed Jul 11 00:22:36 2007 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 l6B7MZ6h007999 for ; Wed, 11 Jul 2007 00:22:36 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l6B7KZSN016487; Wed, 11 Jul 2007 08:20:35 +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 <0JL00080172B5I00@nwk-avmta-2.sfbay.sun.com>; Wed, 11 Jul 2007 00:20:35 -0700 (PDT) Received: from dm-holland-01.uk.sun.com ([129.156.101.192]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JL0007S872AJG00@nwk-avmta-2.sfbay.sun.com>; Wed, 11 Jul 2007 00:20:34 -0700 (PDT) Received: from holland (room101.Holland.Sun.COM [129.159.130.93]) by dm-holland-01.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l6B7JpHE002621; Wed, 11 Jul 2007 08:19:51 +0100 (BST) Date: Wed, 11 Jul 2007 09:19:51 +0200 From: Casper.Dik@Sun.COM Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <20070710225958.GZ14352@Sun.COM> Sender: casper@holland.sun.com To: Nicolas Williams Cc: Scott Rotondo , Jerry Gilliam , Eiji.Ota@Sun.COM, Roch.Bourbonnais@Sun.COM, psarc@Sun.COM, Wesley.Shao@Sun.COM, Shidokht.Yadegari@Sun.COM, Bryan.Cantrill@Sun.COM, Sunay.Tripathi@Sun.COM, Dan.Mick@Sun.COM, pl-direct@Sun.COM Message-id: <200707110719.l6B7JpHE002621@dm-holland-01.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200707101824.l6AIO691177278@jurassic.eng.sun.com> <4693D164.5040405@sun.com> <20070710225958.GZ14352@Sun.COM> Status: RO Content-Length: 911 >On Tue, Jul 10, 2007 at 11:35:16AM -0700, Scott Rotondo wrote: >> Jerry Gilliam wrote: >> >What I'd suggest is keeping this interface with the existing >> >semantics and limitations functioning as is, and introducing >> >a new set of interfaces together with more flexible interval >> >specs. >> >> But that wouldn't accomplish what Casper was suggesting, which is to >> catch uses of the existing interface that supply unreasonably small >> argument values. > >Wouldn't it suffice to add a way to query the current timeout resolution >supported? (and require that this not change until next boot?) No, what I think is that the risk is that a suddenly much higher granularity will cause drivers to malfunction. If you can query the minimum interval that will just lead to drivers just specifying the minimum supported interval (all platforms). But I suggest this only for debug kernels. Casper From sacadmin Wed Jul 11 01:35:01 2007 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 l6B8Z08H009886 for ; Wed, 11 Jul 2007 01:35:01 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l6B8X0Vp004460; Wed, 11 Jul 2007 09:33:01 +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 <0JL000B03AEYSI00@nwk-avmta-2.sfbay.sun.com>; Wed, 11 Jul 2007 01:32:58 -0700 (PDT) Received: from dm-france-01.uk.sun.com ([129.156.101.188]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JL0007H3AEXJH30@nwk-avmta-2.sfbay.sun.com>; Wed, 11 Jul 2007 01:32:58 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by dm-france-01.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l6B8Wmn4016941; Wed, 11 Jul 2007 09:32:49 +0100 (BST) Received: from corn.Sun.COM (corn [129.157.192.240]) by bebop.France.Sun.COM (8.13.8+Sun/8.13.8) with SMTP id l6B8Wkos009593; Wed, 11 Jul 2007 10:32:46 +0200 (MEST) Date: Wed, 11 Jul 2007 10:27:10 +0200 From: Roch - PAE Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <46940BE7.60107@sun.com> To: Dan Mick Cc: Eiji.Ota@sun.com, Roch.Bourbonnais@sun.com, jg@jurassic.sfbay.sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, pl-direct@sun.com Message-id: <18068.37982.585904.320543@gargle.gargle.HOWL> Organization: SUN Microsystems MIME-version: 1.0 X-Mailer: VM 7.19 under 21.1 (patch 3) "Acadia" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <84A04DB1-94E1-4F18-BB5C-AE30E78400E2@Sun.COM> <20070710145924Y.eota@sun.com> <20070710151523Z.eota@sun.com> <46940BE7.60107@sun.com> Phone: (+33).4.76.18.83.20 (x[70]38320) Status: RO Content-Length: 2427 Dan Mick writes: > eiji.ota@sun.com wrote: > > >> The project proposes that X be the same as the system clock interval. > >> Why ? > > > > Because this is the finest resolution.. > > Because the project doesn't want to, at this point, create its own cyclics to > provide the service, but rather uses the clock cyclic to back-end the service. > So it seems that the link to clock is an implementation detail. I don't think we want to hardwire that relationship, So that we could evolve the project callback granularity without changing the clock period. I infer that the project will not be creating new cyclics and schedule callback on the running clock (otherwise the question above remains open).... > ddi_periodic_t > ddi_periodic_add(void (*func)(void *), void *arg, hrtime_t interval, > int level) > > PARAMETERS > func: the callback function > > The callback function will be invoked periodically in the specified > interval. The function is invoked in kernel context if the argument > level is zero. Otherwise it's invoked in interrupt context at the > specified level. > > > arg: the argument passed to the callback function > > > interval: interval time in nanoseconds > > > NOTES > The actual interval time depends on the clock resolution on the system. > The interval less than the clock resolution rounds up to the resolution > internally. For example, if the system resolution is 10ms, less than > 10ms interval rounds up to 10ms internally. > Given that the callback schedule is based on a predefined cyclic (currently of clock periodicity), it would seem to me that the only intervals that are possible are those that are multiples of that period. We should specify we roundup _all_ supplied intervals (not just small ones) to a multiple of the supported resolution, if this is indeed what we plan on doing. ____________________________________________________________________________________ Performance, Availability & Architecture Engineering Roch Bourbonnais Sun Microsystems, Icnc-Grenoble Senior Performance Analyst 180, Avenue De L'Europe, 38330, Montbonnot Saint Martin, France http://icncweb.france/~rbourbon http://blogs.sun.com/roch Roch.Bourbonnais@Sun.Com (+33).4.76.18.83.20 From sacadmin Wed Jul 11 08:10:10 2007 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 l6BFA9UN018381 for ; Wed, 11 Jul 2007 08:10:09 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l6BF7n6P021744; Wed, 11 Jul 2007 16:08:05 +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 <0JL000M4KSPF6A00@brm-avmta-1.central.sun.com>; Wed, 11 Jul 2007 09:08:03 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JL000J1ESPD2F40@brm-avmta-1.central.sun.com>; Wed, 11 Jul 2007 09:08:02 -0600 (MDT) Received: from localhost (ota.SFBay.Sun.COM [129.146.226.183]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l6BF81Nc307166; Wed, 11 Jul 2007 08:08:01 -0700 (PDT) Date: Wed, 11 Jul 2007 08:08:00 -0700 (PDT) From: eiji.ota@sun.com Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <18068.37982.585904.320543@gargle.gargle.HOWL> Sender: Eiji Ota To: Roch.Bourbonnais@sun.com Cc: Dan.Mick@sun.com, jg@jurassic.sfbay.sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, pl-direct@sun.com Message-id: <20070711080800U.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.2.0.264296 Lines: 58 References: <20070710151523Z.eota@sun.com> <46940BE7.60107@sun.com> <18068.37982.585904.320543@gargle.gargle.HOWL> X-Dispatcher: imput version 20000228(IM140) Status: RO Content-Length: 2242 > > >> The project proposes that X be the same as the system clock interval. > > >> Why ? > > > > > > Because this is the finest resolution.. > > > > Because the project doesn't want to, at this point, create its own cyclics to > > provide the service, but rather uses the clock cyclic to back-end the service. > > > > So it seems that the link to clock is an implementation > detail. I don't think we want to hardwire that relationship, > So that we could evolve the project callback granularity > without changing the clock period. > > I infer that the project will not be creating new cyclics > and schedule callback on the running clock (otherwise the > question above remains open).... > > > ddi_periodic_t > > ddi_periodic_add(void (*func)(void *), void *arg, hrtime_t interval, > > int level) > > > > PARAMETERS > > func: the callback function > > > > The callback function will be invoked periodically in the specified > > interval. The function is invoked in kernel context if the argument > > level is zero. Otherwise it's invoked in interrupt context at the > > specified level. > > > > > > arg: the argument passed to the callback function > > > > > > interval: interval time in nanoseconds > > > > > > NOTES > > The actual interval time depends on the clock resolution on the system. > > The interval less than the clock resolution rounds up to the resolution > > internally. For example, if the system resolution is 10ms, less than > > 10ms interval rounds up to 10ms internally. > > > > > Given that the callback schedule is based on a predefined > cyclic (currently of clock periodicity), it would seem to me > that the only intervals that are possible are those that are > multiples of that period. We should specify we roundup > _all_ supplied intervals (not just small ones) to a multiple > of the supported resolution, if this is indeed what we plan > on doing. Which system resolution is actually used on the system is beyond this interface -- currently either 10ms or 1ms though, but it's hard to tell which one is used in the future in general. -Eiji From sacadmin Wed Jul 11 08:15:11 2007 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 l6BFFAsJ018666 for ; Wed, 11 Jul 2007 08:15: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 l6BFCvWK018457; Wed, 11 Jul 2007 23:13:02 +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 <0JL000M23SXNEI00@brm-avmta-1.central.sun.com>; Wed, 11 Jul 2007 09:12:59 -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 <0JL000JWYSXM2840@brm-avmta-1.central.sun.com>; Wed, 11 Jul 2007 09:12:58 -0600 (MDT) Received: from localhost (ota.SFBay.Sun.COM [129.146.226.183]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l6BFCvF8308049; Wed, 11 Jul 2007 08:12:57 -0700 (PDT) Date: Wed, 11 Jul 2007 08:12:57 -0700 (PDT) From: eiji.ota@sun.com Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <20070711080800U.eota@sun.com> Sender: Eiji Ota To: Roch.Bourbonnais@sun.com Cc: Dan.Mick@sun.com, jg@jurassic.sfbay.sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, pl-direct@sun.com Message-id: <20070711081257T.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.2.0.264296 Lines: 64 References: <46940BE7.60107@sun.com> <18068.37982.585904.320543@gargle.gargle.HOWL> <20070711080800U.eota@sun.com> X-Dispatcher: imput version 20000228(IM140) Status: RO Content-Length: 2515 From: eiji.ota@sun.com Subject: Re: 2007/402: Driver Periodic Timeouts Date: Wed, 11 Jul 2007 08:08:00 -0700 (PDT) > > > >> The project proposes that X be the same as the system clock interval. > > > >> Why ? > > > > > > > > Because this is the finest resolution.. > > > > > > Because the project doesn't want to, at this point, create its own cyclics to > > > provide the service, but rather uses the clock cyclic to back-end the service. > > > > > > > So it seems that the link to clock is an implementation > > detail. I don't think we want to hardwire that relationship, > > So that we could evolve the project callback granularity > > without changing the clock period. > > > > I infer that the project will not be creating new cyclics > > and schedule callback on the running clock (otherwise the > > question above remains open).... > > > > > ddi_periodic_t > > > ddi_periodic_add(void (*func)(void *), void *arg, hrtime_t interval, > > > int level) > > > > > > PARAMETERS > > > func: the callback function > > > > > > The callback function will be invoked periodically in the specified > > > interval. The function is invoked in kernel context if the argument > > > level is zero. Otherwise it's invoked in interrupt context at the > > > specified level. > > > > > > > > > arg: the argument passed to the callback function > > > > > > > > > interval: interval time in nanoseconds > > > > > > > > > NOTES > > > The actual interval time depends on the clock resolution on the system. > > > The interval less than the clock resolution rounds up to the resolution > > > internally. For example, if the system resolution is 10ms, less than > > > 10ms interval rounds up to 10ms internally. > > > > > > > > > Given that the callback schedule is based on a predefined > > cyclic (currently of clock periodicity), it would seem to me > > that the only intervals that are possible are those that are > > multiples of that period. We should specify we roundup > > _all_ supplied intervals (not just small ones) to a multiple > > of the supported resolution, if this is indeed what we plan > > on doing. > > Which system resolution is actually used on the system is beyond > this interface -- currently either 10ms or 1ms though, but it's hard > to tell which one is used in the future in general. I mean, what value is used in the future... -Eiji From sacadmin Wed Jul 11 13:58:28 2007 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 l6BKwR8m007832 for ; Wed, 11 Jul 2007 13:58:27 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l6BKuIrc008788; Wed, 11 Jul 2007 21:56:21 +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 <0JL100I8V8TWQE00@brm-avmta-1.central.sun.com>; Wed, 11 Jul 2007 14:56:20 -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 <0JL100DXW8TU3K90@brm-avmta-1.central.sun.com>; Wed, 11 Jul 2007 14:56:18 -0600 (MDT) Received: from localhost (ota.SFBay.Sun.COM [129.146.226.183]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l6BKuHhU527207; Wed, 11 Jul 2007 13:56:17 -0700 (PDT) Date: Wed, 11 Jul 2007 13:56:17 -0700 (PDT) From: eiji.ota@sun.com Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <200707110719.l6B7JpHE002621@dm-holland-01.uk.sun.com> Sender: Eiji Ota To: Casper.Dik@sun.com Cc: Nicolas.Williams@sun.com, Scott.Rotondo@sun.com, jg@jurassic.sfbay.sun.com, Roch.Bourbonnais@sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, Dan.Mick@sun.com, pl-direct@sun.com Message-id: <20070711135617H.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.2.0.264296 Lines: 25 References: <4693D164.5040405@sun.com> <20070710225958.GZ14352@Sun.COM> <200707110719.l6B7JpHE002621@dm-holland-01.uk.sun.com> X-Dispatcher: imput version 20000228(IM140) Status: RO Content-Length: 1077 > >> Jerry Gilliam wrote: > >> >What I'd suggest is keeping this interface with the existing > >> >semantics and limitations functioning as is, and introducing > >> >a new set of interfaces together with more flexible interval > >> >specs. > >> > >> But that wouldn't accomplish what Casper was suggesting, which is to > >> catch uses of the existing interface that supply unreasonably small > >> argument values. > > > >Wouldn't it suffice to add a way to query the current timeout resolution > >supported? (and require that this not change until next boot?) > > No, what I think is that the risk is that a suddenly much higher > granularity will cause drivers to malfunction. > > If you can query the minimum interval that will just lead to drivers just > specifying the minimum supported interval (all platforms). But I suggest > this only for debug kernels. I'm assuming this is a different issue because the interface doesn't change the granularity (the system resolution) at all. What system resolution is used is beyond the proposed interface, I think. -Eiji From sacadmin Wed Jul 11 15:10:46 2007 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 l6BMAjT2011274 for ; Wed, 11 Jul 2007 15:10:45 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l6BM8eCi027176; Wed, 11 Jul 2007 23:08:40 +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 <0JL100203C6FW200@nwk-avmta-2.sfbay.sun.com>; Wed, 11 Jul 2007 15:08:39 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JL100MCOC6FBL40@nwk-avmta-2.sfbay.sun.com>; Wed, 11 Jul 2007 15:08:39 -0700 (PDT) Received: from [10.1.48.172] (dmick1.West.Sun.COM [10.1.48.172]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l6BM8cdg546008; Wed, 11 Jul 2007 15:08:38 -0700 (PDT) Date: Wed, 11 Jul 2007 15:08:09 -0700 From: Dan Mick Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <20070711135617H.eota@sun.com> To: eiji.ota@sun.com Cc: Casper.Dik@sun.com, Nicolas.Williams@sun.com, Scott.Rotondo@sun.com, jg@jurassic.sfbay.sun.com, Roch.Bourbonnais@sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, pl-direct@sun.com Message-id: <469554C9.5060207@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <4693D164.5040405@sun.com> <20070710225958.GZ14352@Sun.COM> <200707110719.l6B7JpHE002621@dm-holland-01.uk.sun.com> <20070711135617H.eota@sun.com> User-Agent: Thunderbird 2.0.0.0 (X11/20070419) Status: RO Content-Length: 983 eiji.ota@sun.com wrote: >> If you can query the minimum interval that will just lead to drivers just >> specifying the minimum supported interval (all platforms). But I suggest >> this only for debug kernels. > > I'm assuming this is a different issue because the interface doesn't > change the granularity (the system resolution) at all. What system resolution > is used is beyond the proposed interface, I think. > > -Eiji I think the point is valid, though. Drivers often need to know exactly how much delay they're getting, and it can't change from release to release (especially can't get smaller). I suspect that "oh, we make some sort of fairly vague promise, but the resolution may be as large as 10ms" isn't very satisfying for many drivers. ATA, for instance, needs a 400ns wait in several places. Granted, it can spin for things that short, but 10ms would just be way way too long. I'm not sure what the right answer is, this concept just makes me nervous. From sacadmin Wed Jul 11 15:14:07 2007 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 l6BME6qq011312 for ; Wed, 11 Jul 2007 15:14:06 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l6BMBoxr020265; Thu, 12 Jul 2007 06:11:56 +0800 (SGT) 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 <0JL100309CBT1L00@nwk-avmta-2.sfbay.sun.com>; Wed, 11 Jul 2007 15:11:53 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JL100MLICBTBL40@nwk-avmta-2.sfbay.sun.com>; Wed, 11 Jul 2007 15:11:53 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l6BMAYNM016500; Wed, 11 Jul 2007 17:10:34 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l6BMAYhc016499; Wed, 11 Jul 2007 17:10:34 -0500 (CDT) Date: Wed, 11 Jul 2007 17:10:34 -0500 From: Nicolas Williams Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <4694142E.8070706@sun.com> To: Scott Rotondo Cc: Jerry Gilliam , Casper.Dik@sun.com, eiji.ota@sun.com, Roch.Bourbonnais@sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, dan.mick@sun.com, pl-direct@sun.com Message-id: <20070711221034.GZ14352@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200707101824.l6AIO691177278@jurassic.eng.sun.com> <4693D164.5040405@sun.com> <20070710225958.GZ14352@Sun.COM> <4694142E.8070706@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: 463 On Tue, Jul 10, 2007 at 04:20:14PM -0700, Scott Rotondo wrote: > Nicolas Williams wrote: > >Wouldn't it suffice to add a way to query the current timeout resolution > >supported? (and require that this not change until next boot?) > > That would work for newly-written code that uses the new query > interface, but it wouldn't help with existing code that makes > unwarranted assumptions about the clock rate. Isn't this a new interface we're talking about? From sacadmin Wed Jul 11 15:16:23 2007 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 l6BMGNmd011367 for ; Wed, 11 Jul 2007 15:16:23 -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 l6BMEKv3018929; Wed, 11 Jul 2007 15:14:22 -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 <0JL10000DCFW1Q00@brm-avmta-1.central.sun.com>; Wed, 11 Jul 2007 16:14:20 -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 <0JL100LFOCFTPJ10@brm-avmta-1.central.sun.com>; Wed, 11 Jul 2007 16:14:18 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l6BMD42Z016509; Wed, 11 Jul 2007 17:13:04 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l6BMD4hH016508; Wed, 11 Jul 2007 17:13:04 -0500 (CDT) Date: Wed, 11 Jul 2007 17:13:04 -0500 From: Nicolas Williams Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <200707110719.l6B7JpHE002621@dm-holland-01.uk.sun.com> To: Casper.Dik@sun.com Cc: Scott Rotondo , Jerry Gilliam , Eiji.Ota@sun.com, Roch.Bourbonnais@sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, Dan.Mick@sun.com, pl-direct@sun.com Message-id: <20070711221304.GA14352@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200707101824.l6AIO691177278@jurassic.eng.sun.com> <4693D164.5040405@sun.com> <20070710225958.GZ14352@Sun.COM> <200707110719.l6B7JpHE002621@dm-holland-01.uk.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: 822 On Wed, Jul 11, 2007 at 09:19:51AM +0200, Casper.Dik@Sun.COM wrote: > >Wouldn't it suffice to add a way to query the current timeout resolution > >supported? (and require that this not change until next boot?) > > No, what I think is that the risk is that a suddenly much higher > granularity will cause drivers to malfunction. With a way to ask what granularity is supported the caller can adjust the way it sets up the periodic timeout. > If you can query the minimum interval that will just lead to drivers just > specifying the minimum supported interval (all platforms). But I suggest > this only for debug kernels. Why? If a driver wants to wait, say, 25ms and the granularity is 10ms then the driver has to decide if it will wait 20ms or 30ms, but at least it gets to know that it can't wait exactly 25ms. From sacadmin Wed Jul 11 15:16:33 2007 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 l6BMGXEY011400 for ; Wed, 11 Jul 2007 15:16:33 -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 l6BMEVjU017581; Wed, 11 Jul 2007 15:14:31 -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 <0JL100303CG75Z00@nwk-avmta-2.sfbay.sun.com>; Wed, 11 Jul 2007 15:14:31 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JL100MY5CG7BO30@nwk-avmta-2.sfbay.sun.com>; Wed, 11 Jul 2007 15:14:31 -0700 (PDT) Received: from localhost (ota.SFBay.Sun.COM [129.146.226.183]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l6BMEVIe547173; Wed, 11 Jul 2007 15:14:31 -0700 (PDT) Date: Wed, 11 Jul 2007 15:14:30 -0700 (PDT) From: eiji.ota@sun.com Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <469554C9.5060207@sun.com> Sender: Eiji Ota To: dan.mick@sun.com Cc: Casper.Dik@sun.com, Nicolas.Williams@sun.com, Scott.Rotondo@sun.com, jg@jurassic.sfbay.sun.com, Roch.Bourbonnais@sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, pl-direct@sun.com Message-id: <20070711151430J.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.2.0.264296 Lines: 28 References: <200707110719.l6B7JpHE002621@dm-holland-01.uk.sun.com> <20070711135617H.eota@sun.com> <469554C9.5060207@sun.com> X-Dispatcher: imput version 20000228(IM140) Status: RO Content-Length: 1508 > >> If you can query the minimum interval that will just lead to drivers just > >> specifying the minimum supported interval (all platforms). But I suggest > >> this only for debug kernels. > > > > I'm assuming this is a different issue because the interface doesn't > > change the granularity (the system resolution) at all. What system resolution > > is used is beyond the proposed interface, I think. > > > > -Eiji > > I think the point is valid, though. Drivers often need to know exactly how much > delay they're getting, and it can't change from release to release (especially > can't get smaller). I suspect that "oh, we make some sort of fairly vague > promise, but the resolution may be as large as 10ms" isn't very satisfying for > many drivers. ATA, for instance, needs a 400ns wait in several places. > Granted, it can spin for things that short, but 10ms would just be way way too long. > > I'm not sure what the right answer is, this concept just makes me nervous. The 10ms resolution is sort of a traditional time limit on Unixes or other OSes. The value is so old that some drivers would complain about it, however, this is so far the acceptable one. Even on linux, the situation is the same; you can expect either 1ms or 10ms timer tick, but if you need a finer one, you should pursue another way, e.g. waiting by spin.. so, changing the system resolution should be a different topic, and I'm afraid trying a finer (say, 100us, or 10us) is a challenge at this moment. -Eiji From sacadmin Wed Jul 11 15:32:52 2007 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 l6BMWq55011989 for ; Wed, 11 Jul 2007 15:32:52 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l6BMUcPe002013; Wed, 11 Jul 2007 23:30:46 +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 <0JL100L01D789H00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 11 Jul 2007 15:30:44 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.104.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JL1004R9D7856B0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 11 Jul 2007 15:30:44 -0700 (PDT) Received: from grimmy.eng.sun.com (grimmy.SFBay.Sun.COM [129.146.108.114]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id l6BMUi3O260905; Wed, 11 Jul 2007 15:30:44 -0700 (PDT) Date: Wed, 11 Jul 2007 15:30:43 -0700 (PDT) From: Randy Fishel Subject: Re: 2007/402: Driver Periodic Timeouts To: eiji.ota@sun.com Cc: casper.dik@sun.com, Nicolas.Williams@sun.com, Scott.Rotondo@sun.com, jg@jurassic.sfbay.sun.com, Roch.Bourbonnais@sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, pl-direct@sun.com Reply-to: Randy Fishel Message-id: <200707112230.l6BMUi3O260905@jurassic.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_48 SunOS 5.10 sun4u sparc Content-type: text/PLAIN Content-transfer-encoding: 7BIT X-Sun-Text-type: ascii X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1819 > > > > I think the point is valid, though. Drivers often need to know exactly how much > > delay they're getting, and it can't change from release to release (especially > > can't get smaller). I suspect that "oh, we make some sort of fairly vague > > promise, but the resolution may be as large as 10ms" isn't very satisfying for > > many drivers. ATA, for instance, needs a 400ns wait in several places. > > Granted, it can spin for things that short, but 10ms would just be way way too long. > > > > I'm not sure what the right answer is, this concept just makes me nervous. > > The 10ms resolution is sort of a traditional time limit on Unixes or other > OSes. The value is so old that some drivers would complain about it, however, > this is so far the acceptable one. Even on linux, the situation is the same; > you can expect either 1ms or 10ms timer tick, but if you need a finer one, > you should pursue another way, e.g. waiting by spin.. so, changing the system > resolution should be a different topic, and I'm afraid trying a finer (say, > 100us, or 10us) is a challenge at this moment. > > -Eiji I am going to add a different twist to this thread of discussion, and ask what is the intended behavior if the period becomes significantly larger than the requested period. In the light of suspend and resume, the next fire time will likely be much larger than the requested, and without a best practice on how to handle periodic timeouts across cpr, might fire before the driver is resumed. Should there maybe also be additional entry points for suspending/resuming these periodic timeouts? Is it better to remove and add in the face of suspend and resume? Will the backend be able to handle potentially excessive delays due to suspension (or even a Xen migration)? ---- Randy From sacadmin Wed Jul 11 15:40:38 2007 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 l6BMecss012660 for ; Wed, 11 Jul 2007 15:40:38 -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 l6BMcbmT023174; Wed, 11 Jul 2007 15:38:37 -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 <0JL100405DKCCJ00@nwk-avmta-2.sfbay.sun.com>; Wed, 11 Jul 2007 15:38:36 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JL100M5KDKCBJ70@nwk-avmta-2.sfbay.sun.com>; Wed, 11 Jul 2007 15:38:36 -0700 (PDT) Received: from localhost (ota.SFBay.Sun.COM [129.146.226.183]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l6BMcZWY550158; Wed, 11 Jul 2007 15:38:35 -0700 (PDT) Date: Wed, 11 Jul 2007 15:38:35 -0700 (PDT) From: eiji.ota@sun.com Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <200707112230.l6BMUi3O260905@jurassic.eng.sun.com> Sender: Eiji Ota To: randyf@jurassic.eng.sun.com Cc: casper.dik@sun.com, Nicolas.Williams@sun.com, Scott.Rotondo@sun.com, jg@jurassic.sfbay.sun.com, Roch.Bourbonnais@sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, pl-direct@sun.com Message-id: <20070711153835U.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.2.0.264296 Lines: 26 References: <200707112230.l6BMUi3O260905@jurassic.eng.sun.com> X-Dispatcher: imput version 20000228(IM140) Status: RO Content-Length: 1345 > > I am going to add a different twist to this thread of discussion, and > ask what is the intended behavior if the period becomes significantly > larger than the requested period. In the light of suspend and resume, > the next fire time will likely be much larger than the requested, and > without a best practice on how to handle periodic timeouts across cpr, > might fire before the driver is resumed. > > Should there maybe also be additional entry points for > suspending/resuming these periodic timeouts? Is it better to remove > and add in the face of suspend and resume? Will the backend be able to > handle potentially excessive delays due to suspension (or even a Xen > migration)? > Actually there are a few factors being able to stop the activity on Solaris; one is, as you told, the suspend-resume function, and another is entering the kernel debug. In those cases, even when it comes, since your kernel is virtually inactive, your handler cannot be invoked. Instead, when your kernel is resumed back or you're back to kernel from the debugger, your handler is invoked. i.e. basically your handler is invoked when time comes, but if kernel is inactive for some reason, it's invoked after it gets back to normal. You don't have to do any extra things for suspend and resume -- this is the same as the current way. -Eiji From sacadmin Wed Jul 11 15:49:08 2007 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 l6BMn8UQ012800 for ; Wed, 11 Jul 2007 15:49:08 -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 l6BMl7G7023289; Wed, 11 Jul 2007 15:47:07 -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 <0JL100205DYI4100@brm-avmta-1.central.sun.com>; Wed, 11 Jul 2007 16:47:06 -0600 (MDT) Received: from jurassic.eng.sun.com ([129.146.228.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JL100LWNDYGPL30@brm-avmta-1.central.sun.com>; Wed, 11 Jul 2007 16:47:05 -0600 (MDT) Received: from grimmy.eng.sun.com (grimmy.SFBay.Sun.COM [129.146.108.114]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id l6BMl4af261255; Wed, 11 Jul 2007 15:47:04 -0700 (PDT) Date: Wed, 11 Jul 2007 15:47:03 -0700 (PDT) From: Randy Fishel Subject: Re: 2007/402: Driver Periodic Timeouts To: randyf@jurassic.eng.sun.com, eiji.ota@sun.com Cc: casper.dik@sun.com, Nicolas.Williams@sun.com, Scott.Rotondo@sun.com, jg@jurassic.sfbay.sun.com, Roch.Bourbonnais@sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, pl-direct@sun.com Reply-to: Randy Fishel Message-id: <200707112247.l6BMl4af261255@jurassic.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_48 SunOS 5.10 sun4u sparc Content-type: text/PLAIN Content-transfer-encoding: 7BIT X-Sun-Text-type: ascii X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1911 > > I am going to add a different twist to this thread of discussion, and > > ask what is the intended behavior if the period becomes significantly > > larger than the requested period. In the light of suspend and resume, > > the next fire time will likely be much larger than the requested, and > > without a best practice on how to handle periodic timeouts across cpr, > > might fire before the driver is resumed. > > > > Should there maybe also be additional entry points for > > suspending/resuming these periodic timeouts? Is it better to remove > > and add in the face of suspend and resume? Will the backend be able to > > handle potentially excessive delays due to suspension (or even a Xen > > migration)? > > > > Actually there are a few factors being able to stop the activity on Solaris; > one is, as you told, the suspend-resume function, and another is entering > the kernel debug. In those cases, even when it comes, since your kernel > is virtually inactive, your handler cannot be invoked. Instead, when your > kernel is resumed back or you're back to kernel from the debugger, your > handler is invoked. i.e. basically your handler is invoked when time comes, > but if kernel is inactive for some reason, it's invoked after it gets back > to normal. You don't have to do any extra things for suspend and resume -- > this is the same as the current way. > > -Eiji There have been interesting interactions within poorly written drivers with suspended activity, including the drivers that panic or hang on suspend/resume because a timeout fired after the driver was suspended and before it was resumed (the kernel is _still_ running, but the driver shouldn't be). Is the claim here, that this interface intends to neither improve nor regress the current behavior (though if adding an interface, I would much rather see attempts to improve previous poor behavior)? ---- Randy From sacadmin Wed Jul 11 15:52:54 2007 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 l6BMqrig012838 for ; Wed, 11 Jul 2007 15:52:53 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l6BMoiHm006491; Wed, 11 Jul 2007 23:50:48 +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 <0JL100207E4KDK00@brm-avmta-1.central.sun.com>; Wed, 11 Jul 2007 16:50:44 -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 <0JL100L2SE4IPJ40@brm-avmta-1.central.sun.com>; Wed, 11 Jul 2007 16:50:42 -0600 (MDT) Received: from localhost (ota.SFBay.Sun.COM [129.146.226.183]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l6BMofai552270; Wed, 11 Jul 2007 15:50:41 -0700 (PDT) Date: Wed, 11 Jul 2007 15:50:40 -0700 (PDT) From: eiji.ota@sun.com Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <200707112247.l6BMl4af261255@jurassic.eng.sun.com> Sender: Eiji Ota To: randyf@jurassic.eng.sun.com Cc: casper.dik@sun.com, Nicolas.Williams@sun.com, Scott.Rotondo@sun.com, jg@jurassic.sfbay.sun.com, Roch.Bourbonnais@sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, pl-direct@sun.com Message-id: <20070711155040M.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.2.0.264296 Lines: 42 References: <200707112247.l6BMl4af261255@jurassic.eng.sun.com> X-Dispatcher: imput version 20000228(IM140) Status: RO Content-Length: 2165 > > > I am going to add a different twist to this thread of discussion, and > > > ask what is the intended behavior if the period becomes significantly > > > larger than the requested period. In the light of suspend and resume, > > > the next fire time will likely be much larger than the requested, and > > > without a best practice on how to handle periodic timeouts across cpr, > > > might fire before the driver is resumed. > > > > > > Should there maybe also be additional entry points for > > > suspending/resuming these periodic timeouts? Is it better to remove > > > and add in the face of suspend and resume? Will the backend be able to > > > handle potentially excessive delays due to suspension (or even a Xen > > > migration)? > > > > > > > Actually there are a few factors being able to stop the activity on Solaris; > > one is, as you told, the suspend-resume function, and another is entering > > the kernel debug. In those cases, even when it comes, since your kernel > > is virtually inactive, your handler cannot be invoked. Instead, when your > > kernel is resumed back or you're back to kernel from the debugger, your > > handler is invoked. i.e. basically your handler is invoked when time comes, > > but if kernel is inactive for some reason, it's invoked after it gets back > > to normal. You don't have to do any extra things for suspend and resume -- > > this is the same as the current way. > > > > -Eiji > > There have been interesting interactions within poorly written drivers > with suspended activity, including the drivers that panic or hang on > suspend/resume because a timeout fired after the driver was suspended > and before it was resumed (the kernel is _still_ running, but the > driver shouldn't be). > > Is the claim here, that this interface intends to neither improve nor > regress the current behavior (though if adding an interface, I would > much rather see attempts to improve previous poor behavior)? > About the suspend-resume, yes, there is no additions or removals. If you observe a panic or hang on Solaris during the suspend or resume, I'm afraid this would be an implementation flaw.. -Eiji From sacadmin Wed Jul 11 16:26:22 2007 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 l6BNQLvC014404 for ; Wed, 11 Jul 2007 16:26:22 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l6BNO9QH008801; Thu, 12 Jul 2007 07:24:10 +0800 (SGT) 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 <0JL100605FO9BI00@nwk-avmta-2.sfbay.sun.com>; Wed, 11 Jul 2007 16:24:09 -0700 (PDT) Received: from eastmail4bur.east.Sun.COM ([129.148.13.1]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JL100M44FO8BD80@nwk-avmta-2.sfbay.sun.com>; Wed, 11 Jul 2007 16:24:09 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l6BNN30G001369; Wed, 11 Jul 2007 19:23:06 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l6BNN06W006387; Wed, 11 Jul 2007 19:23:00 -0400 (EDT) Date: Wed, 11 Jul 2007 19:22:59 -0400 From: Bill Sommerfeld Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <20070711155040M.eota@sun.com> To: Eiji.Ota@sun.com Cc: randyf@jurassic.eng.sun.com, Casper.Dik@sun.com, Nicolas.Williams@sun.com, Scott.Rotondo@sun.com, jg@jurassic.sfbay.sun.com, Roch.Bourbonnais@sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, pl-direct@sun.com Message-id: <1184196179.3197.76.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.10.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200707112247.l6BMl4af261255@jurassic.eng.sun.com> <20070711155040M.eota@sun.com> Status: RO Content-Length: 1445 On Wed, 2007-07-11 at 15:50 -0700, Eiji.Ota@sun.com wrote: > > There have been interesting interactions within poorly written drivers > > with suspended activity, including the drivers that panic or hang on > > suspend/resume because a timeout fired after the driver was suspended > > and before it was resumed (the kernel is _still_ running, but the > > driver shouldn't be). > > > > Is the claim here, that this interface intends to neither improve nor > > regress the current behavior (though if adding an interface, I would > > much rather see attempts to improve previous poor behavior)? > > > > About the suspend-resume, yes, there is no additions or removals. > If you observe a panic or hang on Solaris during the suspend or resume, > I'm afraid this would be an implementation flaw.. so, there would seem to be at least two ways to handle this: 1) add a dev_info_t * parameter to ddi_periodic_add; framework ensures that timer code can't run between the time that the detach callback at suspend is invoked and the time that the attach callback is called at resume. 2) require that non-buggy drivers disable any outstanding timers before a DDI_SUSPEND call to their detach routine returns. (1) might also allow the framework to prevent a driver from being unloaded while a timeout was still pending. (I helped to debug a driver that let this happen once and it was a pain to sort out what had happened). - Bill From sacadmin Wed Jul 11 16:34:51 2007 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 l6BNYoPR014844 for ; Wed, 11 Jul 2007 16:34:50 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l6BNWccG015705; Thu, 12 Jul 2007 00:32:43 +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 <0JL100457G2FMK00@brm-avmta-1.central.sun.com>; Wed, 11 Jul 2007 17:32:39 -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 <0JL100LC2G2APJ60@brm-avmta-1.central.sun.com>; Wed, 11 Jul 2007 17:32:35 -0600 (MDT) Received: from localhost (ota.SFBay.Sun.COM [129.146.226.183]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l6BNWXxL559278; Wed, 11 Jul 2007 16:32:33 -0700 (PDT) Date: Wed, 11 Jul 2007 16:32:33 -0700 (PDT) From: eiji.ota@Sun.COM Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <1184196179.3197.76.camel@thunk> Sender: Eiji Ota To: sommerfeld@Sun.COM Cc: randyf@jurassic.eng.sun.com, Casper.Dik@Sun.COM, Nicolas.Williams@Sun.COM, Scott.Rotondo@Sun.COM, jg@jurassic.sfbay.sun.com, Roch.Bourbonnais@Sun.COM, psarc@Sun.COM, Wesley.Shao@Sun.COM, Shidokht.Yadegari@Sun.COM, Bryan.Cantrill@Sun.COM, Sunay.Tripathi@Sun.COM, pl-direct@Sun.COM Message-id: <20070711163233C.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.2.0.264296 Lines: 46 References: <200707112247.l6BMl4af261255@jurassic.eng.sun.com> <20070711155040M.eota@sun.com> <1184196179.3197.76.camel@thunk> X-Dispatcher: imput version 20000228(IM140) Status: RO Content-Length: 2019 > > > There have been interesting interactions within poorly written drivers > > > with suspended activity, including the drivers that panic or hang on > > > suspend/resume because a timeout fired after the driver was suspended > > > and before it was resumed (the kernel is _still_ running, but the > > > driver shouldn't be). > > > > > > Is the claim here, that this interface intends to neither improve nor > > > regress the current behavior (though if adding an interface, I would > > > much rather see attempts to improve previous poor behavior)? > > > > > > > About the suspend-resume, yes, there is no additions or removals. > > If you observe a panic or hang on Solaris during the suspend or resume, > > I'm afraid this would be an implementation flaw.. > > so, there would seem to be at least two ways to handle this: > > 1) add a dev_info_t * parameter to ddi_periodic_add; framework ensures > that timer code can't run between the time that the detach callback at > suspend is invoked and the time that the attach callback is called at > resume. > > 2) require that non-buggy drivers disable any outstanding timers before > a DDI_SUSPEND call to their detach routine returns. > > (1) might also allow the framework to prevent a driver from being > unloaded while a timeout was still pending. (I helped to debug a driver > that let this happen once and it was a pain to sort out what had > happened). I think I can take them as much as possible here, but the currently there is a guard to prevent the framework from calling the handler during the suspend-resume. (the cpr sets the flag in the flamework when the suspend starts, the framework doesn't invoke the handler until it's clears. The cpr clears it when kernel gets back to normal) I thought it was enough to keep away from it, though. Also, drivers should take responsibility for canceling the request when it's detached. Those things are the same as timeout(9F) does currently. Please let me know if this way is not enough. -Eiji From sacadmin Thu Jul 12 01:18:37 2007 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 l6C8Ib6d026189 for ; Thu, 12 Jul 2007 01:18:37 -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 l6C8Fk8F005491; Thu, 12 Jul 2007 02:15:47 -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 <0JL200B0T4BPZ600@nwk-avmta-2.sfbay.sun.com>; Thu, 12 Jul 2007 01:16:37 -0700 (PDT) Received: from dm-france-01.uk.sun.com ([129.156.101.188]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JL200A9X4BOH540@nwk-avmta-2.sfbay.sun.com>; Thu, 12 Jul 2007 01:16:37 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by dm-france-01.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l6C8GUwd006973; Thu, 12 Jul 2007 09:16:30 +0100 (BST) Received: from corn.Sun.COM (corn [129.157.192.240]) by bebop.France.Sun.COM (8.13.8+Sun/8.13.8) with SMTP id l6C8GI9U019444; Thu, 12 Jul 2007 10:16:18 +0200 (MEST) Date: Thu, 12 Jul 2007 10:10:38 +0200 From: Roch - PAE Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <20070711081257T.eota@sun.com> To: Eiji.Ota@sun.com Cc: Roch.Bourbonnais@sun.com, Dan.Mick@sun.com, jg@jurassic.sfbay.sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, pl-direct@sun.com Message-id: <18069.57854.546654.836409@gargle.gargle.HOWL> Organization: SUN Microsystems MIME-version: 1.0 X-Mailer: VM 7.19 under 21.1 (patch 3) "Acadia" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <46940BE7.60107@sun.com> <18068.37982.585904.320543@gargle.gargle.HOWL> <20070711080800U.eota@sun.com> <20070711081257T.eota@sun.com> Phone: (+33).4.76.18.83.20 (x[70]38320) Status: RO Content-Length: 3172 Eiji.Ota@Sun.COM writes: > From: eiji.ota@sun.com > Subject: Re: 2007/402: Driver Periodic Timeouts > Date: Wed, 11 Jul 2007 08:08:00 -0700 (PDT) > > > > > >> The project proposes that X be the same as the system clock interval. > > > > >> Why ? > > > > > > > > > > Because this is the finest resolution.. > > > > > > > > Because the project doesn't want to, at this point, create its own cyclics to > > > > provide the service, but rather uses the clock cyclic to back-end the service. > > > > > > > > > > So it seems that the link to clock is an implementation > > > detail. I don't think we want to hardwire that relationship, > > > So that we could evolve the project callback granularity > > > without changing the clock period. > > > > > > I infer that the project will not be creating new cyclics > > > and schedule callback on the running clock (otherwise the > > > question above remains open).... > > > > > > > ddi_periodic_t > > > > ddi_periodic_add(void (*func)(void *), void *arg, hrtime_t interval, > > > > int level) > > > > > > > > PARAMETERS > > > > func: the callback function > > > > > > > > The callback function will be invoked periodically in the specified > > > > interval. The function is invoked in kernel context if the argument > > > > level is zero. Otherwise it's invoked in interrupt context at the > > > > specified level. > > > > > > > > > > > > arg: the argument passed to the callback function > > > > > > > > > > > > interval: interval time in nanoseconds > > > > > > > > > > > > NOTES > > > > The actual interval time depends on the clock resolution on the system. > > > > The interval less than the clock resolution rounds up to the resolution > > > > internally. For example, if the system resolution is 10ms, less than > > > > 10ms interval rounds up to 10ms internally. > > > > > > > > > > > > > Given that the callback schedule is based on a predefined > > > cyclic (currently of clock periodicity), it would seem to me > > > that the only intervals that are possible are those that are > > > multiples of that period. We should specify we roundup > > > _all_ supplied intervals (not just small ones) to a multiple > > > of the supported resolution, if this is indeed what we plan > > > on doing. > > > > Which system resolution is actually used on the system is beyond > > this interface -- currently either 10ms or 1ms though, but it's hard > > to tell which one is used in the future in general. > > I mean, what value is used in the future... > > -Eiji I think a hires_tick Solaris kernel should have no bearing on this case; Do we really run this kernel somewhere ? So how about we say in the PARAMETERS section: Interval Supplied intervals are rounded up to a resolution of 10ms. The supported resolution may change in a future release. Note that I think it would be better to have a mean to query the supported resolution and the text would then make reference to that mean. -r From sacadmin Thu Jul 12 04:38:57 2007 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 l6CBcuS7029838 for ; Thu, 12 Jul 2007 04:38:57 -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 l6CBaZtq017480; Thu, 12 Jul 2007 19:36:52 +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 <0JL200A09DLGL100@nwk-avmta-1.sfbay.Sun.COM>; Thu, 12 Jul 2007 04:36:52 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JL200JVPDLFFE90@nwk-avmta-1.sfbay.Sun.COM>; Thu, 12 Jul 2007 04:36:51 -0700 (PDT) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6CBapMJ000591; Thu, 12 Jul 2007 11:36:51 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JL200401D38ZA00@mail-amer.sun.com> (original mail from Mark.Johnson@Sun.COM); Thu, 12 Jul 2007 05:36:51 -0600 (MDT) Received: from mrj.local ([75.68.54.173]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JL200HAKDLB6MA9@mail-amer.sun.com>; Thu, 12 Jul 2007 05:36:50 -0600 (MDT) Date: Thu, 12 Jul 2007 07:38:17 -0400 From: Mark Johnson Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <18069.57854.546654.836409@gargle.gargle.HOWL> Sender: Mark.Johnson@sun.com To: Roch - PAE Cc: Eiji.Ota@sun.com, Dan.Mick@sun.com, jg@jurassic.sfbay.sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, pl-direct@sun.com Message-id: <469612A9.5060808@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <46940BE7.60107@sun.com> <18068.37982.585904.320543@gargle.gargle.HOWL> <20070711080800U.eota@sun.com> <20070711081257T.eota@sun.com> <18069.57854.546654.836409@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) Status: RO Content-Length: 1165 Roch - PAE wrote: > Eiji.Ota@Sun.COM writes: > > From: eiji.ota@sun.com > I think a hires_tick Solaris kernel should have no bearing > on this case; Do we really run this kernel somewhere ? > > So how about we say in the PARAMETERS section: > > Interval > > Supplied intervals are rounded up to a resolution of 10ms. > The supported resolution may change in a future release. > > Note that I think it would be better to have a mean to query > the supported resolution and the text would then make > reference to that mean. I agree with Roch that you should add a function to query the resolution, e.g. ddi_periodic_resolution(9F). e.g. "Supplied intervals are rounded up to the resolution specified in ddi_periodic_resolution(9F)." I also think Casper's original comment should be addressed in the implementation. e.g. a driver uses a resolutions which is unreasonable e.g. 5uS getting rounded up to 10mS. However, I would probably do a warning in the debug kernel (or based on a patchable which defaults to on in a DEBUG build) vs panic'ing the system. MRJ -- Mark Johnson Sun Microsystems, Inc. (781) 442-0869 From sacadmin Thu Jul 12 05:28:02 2007 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 l6CCS1Vh001057 for ; Thu, 12 Jul 2007 05:28:01 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l6CCPqtx023661; Thu, 12 Jul 2007 13:25:55 +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 <0JL20050BFV57K00@brm-avmta-1.central.sun.com>; Thu, 12 Jul 2007 06:25:53 -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 <0JL200H23FV3CX90@brm-avmta-1.central.sun.com>; Thu, 12 Jul 2007 06:25:52 -0600 (MDT) Received: from localhost (ota.SFBay.Sun.COM [129.146.226.183]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l6CCPpjk681451; Thu, 12 Jul 2007 05:25:51 -0700 (PDT) Date: Thu, 12 Jul 2007 05:25:49 -0700 (PDT) From: eiji.ota@sun.com Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <469612A9.5060808@sun.com> Sender: Eiji Ota To: Mark.Johnson@sun.com Cc: Roch.Bourbonnais@sun.com, Dan.Mick@sun.com, jg@jurassic.sfbay.sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, pl-direct@sun.com Message-id: <20070712052549I.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.2.0.264296 Lines: 48 References: <20070711081257T.eota@sun.com> <18069.57854.546654.836409@gargle.gargle.HOWL> <469612A9.5060808@sun.com> X-Dispatcher: imput version 20000228(IM140) Status: RO Content-Length: 1821 Hi, > > I think a hires_tick Solaris kernel should have no bearing > > on this case; Do we really run this kernel somewhere ? > > > > So how about we say in the PARAMETERS section: > > > > Interval > > > > Supplied intervals are rounded up to a resolution of 10ms. > > The supported resolution may change in a future release. > > > > Note that I think it would be better to have a mean to query > > the supported resolution and the text would then make > > reference to that mean. > > > I agree with Roch that you should add a function to query the > resolution, e.g. ddi_periodic_resolution(9F). > > e.g. "Supplied intervals are rounded up to the resolution > specified in ddi_periodic_resolution(9F)." One comment about this: suppose you specify 25ms with the 10ms resolution, then what you can expect is the handler is invoked between 20ms and 30ms. (+- 5ms error) however, since the cyclic interrupt itself is based on nanoseconds, if you round up 25ms to 30ms, time is likely between 25ms and 35ms (+5ms shifted), so with roundup or without roundup, the actual behavior can be different. I'm a bit concerned with this difference. From this point of view, I'd rather want to use nanosecond as it is though I'd like to hear others' opinions. > I also think Casper's original comment should be addressed > in the implementation. > > e.g. a driver uses a resolutions which is unreasonable e.g. > 5uS getting rounded up to 10mS. However, I would probably > do a warning in the debug kernel (or based on a patchable > which defaults to on in a DEBUG build) vs panic'ing the > system. Some drivers specify 0 to timeout(9F) if they want an immediate timeout currently. so even now we can face quite small intervals. The implementation will put the warning in that case as Mark told. -Eiji From sacadmin Thu Jul 12 05:33:19 2007 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 l6CCXING001121 for ; Thu, 12 Jul 2007 05:33: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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l6CCV7q4025141; Thu, 12 Jul 2007 13:31: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 <0JL200001G44EP00@nwk-avmta-2.sfbay.sun.com>; Thu, 12 Jul 2007 05:31:16 -0700 (PDT) Received: from dm-holland-01.uk.sun.com ([129.156.101.192]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JL200GNGG43EH80@nwk-avmta-2.sfbay.sun.com>; Thu, 12 Jul 2007 05:31:16 -0700 (PDT) Received: from holland (room101.Holland.Sun.COM [129.159.130.93]) by dm-holland-01.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l6CCV6nU026116; Thu, 12 Jul 2007 13:31:07 +0100 (BST) Date: Thu, 12 Jul 2007 14:31:06 +0200 From: Casper.Dik@sun.com Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <20070712052549I.eota@sun.com> Sender: casper@holland.sun.com To: Eiji.Ota@sun.com Cc: Mark.Johnson@sun.com, Roch.Bourbonnais@sun.com, Dan.Mick@sun.com, jg@jurassic.sfbay.sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, pl-direct@sun.com Message-id: <200707121231.l6CCV6nU026116@dm-holland-01.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070711081257T.eota@sun.com> <18069.57854.546654.836409@gargle.gargle.HOWL> <469612A9.5060808@sun.com> <20070712052549I.eota@sun.com> Status: RO Content-Length: 510 >Some drivers specify 0 to timeout(9F) if they want an immediate >timeout currently. so even now we can face quite small intervals. >The implementation will put the warning in that case as Mark told. An immediate timeout is quite different from a continuous call back. (I am actually curious what prevents us from having random intervals; on SPARCv9 I know this is easy using tickcmp/stickcmp. But what about x86/amd64?) I really think such a precise timeout source would be hugely beneficial. Casper From sacadmin Thu Jul 12 05:35:08 2007 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 l6CCZ7jt001274 for ; Thu, 12 Jul 2007 05:35:07 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l6CCWmQa004019; Thu, 12 Jul 2007 20:32:56 +0800 (SGT) 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 <0JL200025G6UHA00@nwk-avmta-2.sfbay.sun.com>; Thu, 12 Jul 2007 05:32:54 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JL200GTUG6TEH80@nwk-avmta-2.sfbay.sun.com>; Thu, 12 Jul 2007 05:32:53 -0700 (PDT) Received: from localhost (ota.SFBay.Sun.COM [129.146.226.183]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l6CCWqvO682415; Thu, 12 Jul 2007 05:32:52 -0700 (PDT) Date: Thu, 12 Jul 2007 05:32:52 -0700 (PDT) From: Eiji.Ota@sun.com Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <20070712052549I.eota@sun.com> Sender: Eiji Ota To: Mark.Johnson@sun.com Cc: Roch.Bourbonnais@sun.com, Dan.Mick@sun.com, jg@jurassic.sfbay.sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, pl-direct@sun.com Message-id: <20070712053252Y.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.2.0.264296 Lines: 12 References: <18069.57854.546654.836409@gargle.gargle.HOWL> <469612A9.5060808@sun.com> <20070712052549I.eota@sun.com> X-Dispatcher: imput version 20000228(IM140) Status: RO Content-Length: 492 > > Some drivers specify 0 to timeout(9F) if they want an immediate > timeout currently. so even now we can face quite small intervals. > The implementation will put the warning in that case as Mark told. > Just double-check. I know some drivers use 0 as the interval and pass it to timeout(9F). Probably this is a bad custom, but the reality anyway. Putting the warning every time we see this kind of bad habit could be a call generator? If so, it would be better ignoring them..? -Eiji From sacadmin Thu Jul 12 05:40:54 2007 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 l6CCerIT001366 for ; Thu, 12 Jul 2007 05:40:53 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l6CCcYRn005390; Thu, 12 Jul 2007 20:38:49 +0800 (SGT) 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 <0JL200001GGORU00@nwk-avmta-2.sfbay.sun.com>; Thu, 12 Jul 2007 05:38:48 -0700 (PDT) Received: from dm-holland-01.uk.sun.com ([129.156.101.192]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JL200G4BGGNEU90@nwk-avmta-2.sfbay.sun.com>; Thu, 12 Jul 2007 05:38:48 -0700 (PDT) Received: from holland (room101.Holland.Sun.COM [129.159.130.93]) by dm-holland-01.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l6CCcQxf027491; Thu, 12 Jul 2007 13:38:26 +0100 (BST) Date: Thu, 12 Jul 2007 14:38:25 +0200 From: Casper.Dik@sun.com Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <20070712053252Y.eota@sun.com> Sender: casper@holland.sun.com To: Eiji.Ota@sun.com Cc: Mark.Johnson@sun.com, Roch.Bourbonnais@sun.com, Dan.Mick@sun.com, jg@jurassic.sfbay.sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, pl-direct@sun.com Message-id: <200707121238.l6CCcQxf027491@dm-holland-01.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <18069.57854.546654.836409@gargle.gargle.HOWL> <469612A9.5060808@sun.com> <20070712052549I.eota@sun.com> <20070712053252Y.eota@sun.com> Status: RO Content-Length: 931 >> >> Some drivers specify 0 to timeout(9F) if they want an immediate >> timeout currently. so even now we can face quite small intervals. >> The implementation will put the warning in that case as Mark told. >> > >Just double-check. I know some drivers use 0 as the interval and pass >it to timeout(9F). Probably this is a bad custom, but the reality anyway. >Putting the warning every time we see this kind of bad habit could be >a call generator? If so, it would be better ignoring them..? What is this used for? A one-time soft interrupt? I would assume that a driver adds a periodic only once per instance; one warning per driver per instance seems managable. Once for each timeout(0), OTOH, seems not. And what about drv_usectohz()? I think its callers need to be vetted in ON and possibly a warning added to debug kernels for preposterous values as I know from experience that such values do break things. Casper From sacadmin Thu Jul 12 05:46:15 2007 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 l6CCkEcs001438 for ; Thu, 12 Jul 2007 05:46:14 -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 l6CCi0rZ007182; Thu, 12 Jul 2007 20:44:01 +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 <0JL20061BGPB1300@brm-avmta-1.central.sun.com>; Thu, 12 Jul 2007 06:43:59 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JL200HSDGP3DA80@brm-avmta-1.central.sun.com>; Thu, 12 Jul 2007 06:43:52 -0600 (MDT) Received: from localhost (ota.SFBay.Sun.COM [129.146.226.183]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l6CChmbU683361; Thu, 12 Jul 2007 05:43:48 -0700 (PDT) Date: Thu, 12 Jul 2007 05:43:47 -0700 (PDT) From: eiji.ota@sun.com Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <200707121238.l6CCcQxf027491@dm-holland-01.uk.sun.com> Sender: Eiji Ota To: Casper.Dik@sun.com Cc: Mark.Johnson@sun.com, Roch.Bourbonnais@sun.com, Dan.Mick@sun.com, jg@jurassic.sfbay.sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, pl-direct@sun.com Message-id: <20070712054347B.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.2.0.264296 Lines: 26 References: <20070712052549I.eota@sun.com> <20070712053252Y.eota@sun.com> <200707121238.l6CCcQxf027491@dm-holland-01.uk.sun.com> X-Dispatcher: imput version 20000228(IM140) Status: RO Content-Length: 1083 > >> > >> Some drivers specify 0 to timeout(9F) if they want an immediate > >> timeout currently. so even now we can face quite small intervals. > >> The implementation will put the warning in that case as Mark told. > >> > > > >Just double-check. I know some drivers use 0 as the interval and pass > >it to timeout(9F). Probably this is a bad custom, but the reality anyway. > >Putting the warning every time we see this kind of bad habit could be > >a call generator? If so, it would be better ignoring them..? > > What is this used for? A one-time soft interrupt? > > I would assume that a driver adds a periodic only once per instance; > one warning per driver per instance seems managable. Yes, one warning per driver per instance seems OK. (not every time the handler is invoked.. :)) Then I take this. > Once for each timeout(0), OTOH, seems not. > > And what about drv_usectohz()? I think its callers need to be vetted in > ON and possibly a warning added to debug kernels for preposterous values > as I know from experience that such values do break things. -Eiji From sacadmin Fri Jul 13 06:16:49 2007 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 l6DDGn0Q009799 for ; Fri, 13 Jul 2007 06:16:49 -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 l6DDEoLr025506; Fri, 13 Jul 2007 06:14:51 -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 <0JL400105CSQ0B00@brm-avmta-1.central.sun.com>; Fri, 13 Jul 2007 07:14:50 -0600 (MDT) Received: from dm-france-01.uk.sun.com ([129.156.101.188]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JL400M5FCSNLW20@brm-avmta-1.central.sun.com>; Fri, 13 Jul 2007 07:14:48 -0600 (MDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by dm-france-01.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l6DDEf3a016802; Fri, 13 Jul 2007 14:14:41 +0100 (BST) Received: from corn.Sun.COM (corn [129.157.192.240]) by bebop.France.Sun.COM (8.13.8+Sun/8.13.8) with SMTP id l6DDEYKA010419; Fri, 13 Jul 2007 15:14:34 +0200 (MEST) Date: Fri, 13 Jul 2007 15:08:53 +0200 From: Roch - PAE Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <20070712052549I.eota@sun.com> To: Eiji.Ota@sun.com Cc: Mark.Johnson@sun.com, Roch.Bourbonnais@sun.com, Dan.Mick@sun.com, jg@jurassic.sfbay.sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, pl-direct@sun.com Message-id: <18071.31077.503665.655427@gargle.gargle.HOWL> Organization: SUN Microsystems MIME-version: 1.0 X-Mailer: VM 7.19 under 21.1 (patch 3) "Acadia" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070711081257T.eota@sun.com> <18069.57854.546654.836409@gargle.gargle.HOWL> <469612A9.5060808@sun.com> <20070712052549I.eota@sun.com> Phone: (+33).4.76.18.83.20 (x[70]38320) Status: RO Content-Length: 1789 > e.g. "Supplied intervals are rounded up to the resolution > specified in ddi_periodic_resolution(9F)." One comment about this: When I setup for a periodic timeout I do not have expectation regarding the exact moment on the callback but I do have expectation regarding the interval between 2 callbacks. suppose you specify 25ms with the 10ms resolution, then what you can expect is the handler is invoked between 20ms and 30ms. (+- 5ms error) In the case where we clearly state that we round up the interval to the resolution, the situation is that the expected interval differs from the requested interval. The requested 25ms becomes the expected 30ms. The callback occur every 30ms, as expected, with very little error. What you suggest is that for a requested 25ms interval, the user would see sometimes 20ms between callbacks and sometimes 30ms but on average 25ms. If this is the plan, it should be more clearly stated. I don't think it's a viable option. however, since the cyclic interrupt itself is based on nanoseconds, if you round up 25ms to 30ms, time is likely between 25ms and 35ms (+5ms shifted), so with roundup or without roundup, the actual behavior can be different. I'm a bit concerned with this difference. From this point of view, I'd rather want to use nanosecond as it is though I'd like to hear others' opinions. -r ____________________________________________________________________________________ Roch Bourbonnais Sun Microsystems, Icnc-Grenoble Senior Performance Analyst 180, Avenue De L'Europe, 38330, Montbonnot Saint Martin, France http://icncweb.france/~rbourbon http://blogs.sun.com/roch Roch.Bourbonnais@Sun.Com (+33).4.76.18.83.20 From sacadmin Fri Jul 13 06:44:21 2007 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 l6DDiK1S010004 for ; Fri, 13 Jul 2007 06:44:21 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l6DDfpwo027729; Fri, 13 Jul 2007 14:42:15 +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 <0JL400701E2CMA00@nwk-avmta-2.sfbay.sun.com>; Fri, 13 Jul 2007 06:42:12 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JL40060DE2B9220@nwk-avmta-2.sfbay.sun.com>; Fri, 13 Jul 2007 06:42:12 -0700 (PDT) Received: from localhost (ota.SFBay.Sun.COM [129.146.226.183]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l6DDgBs2151826; Fri, 13 Jul 2007 06:42:11 -0700 (PDT) Date: Fri, 13 Jul 2007 06:42:10 -0700 (PDT) From: eiji.ota@sun.com Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <18071.31077.503665.655427@gargle.gargle.HOWL> Sender: Eiji Ota To: Roch.Bourbonnais@sun.com Cc: Mark.Johnson@sun.com, Dan.Mick@sun.com, jg@jurassic.sfbay.sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, pl-direct@sun.com Message-id: <20070713064210H.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.2.0.264296 Lines: 42 References: <469612A9.5060808@sun.com> <20070712052549I.eota@sun.com> <18071.31077.503665.655427@gargle.gargle.HOWL> X-Dispatcher: imput version 20000228(IM140) Status: RO Content-Length: 1959 > > e.g. "Supplied intervals are rounded up to the resolution > > specified in ddi_periodic_resolution(9F)." > > One comment about this: > > When I setup for a periodic timeout I do not have > expectation regarding the exact moment on the callback but I > do have expectation regarding the interval between 2 > callbacks. > > suppose you specify 25ms with the 10ms resolution, then what you can > expect is the handler is invoked between 20ms and 30ms. (+- 5ms error) > > In the case where we clearly state that we round up the > interval to the resolution, the situation is that the > expected interval differs from the requested interval. The > requested 25ms becomes the expected 30ms. The callback occur > every 30ms, as expected, with very little error. > > What you suggest is that for a requested 25ms interval, the > user would see sometimes 20ms between callbacks and sometimes > 30ms but on average 25ms. If this is the plan, it should be > more clearly stated. I don't think it's a viable option. Yes, the 25ms average is the expected one; in reality we have some factors e.g. higher interrupts than 10 (clock level) bothering clock, but the interrupt is occurred basend on nanoseconds, and every fire can have an error. So the document explains this error briefly, but the expected average is 25ms in this case. As well as timeout(9F), the exact time interval over which the function takes effect cannot be guaranteed, but the value given is a close approximation. > > however, since the cyclic interrupt itself is based on nanoseconds, if > you round up 25ms to 30ms, time is likely between 25ms and 35ms > (+5ms shifted), so with roundup or without roundup, the actual behavior > can be different. I'm a bit concerned with this difference. From this point > of view, I'd rather want to use nanosecond as it is though I'd like to hear > others' opinions. -Eiji From sacadmin Fri Jul 13 10:39:28 2007 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 l6DHdSkh015633 for ; Fri, 13 Jul 2007 10:39:28 -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 l6DHbNLx004960; Fri, 13 Jul 2007 10:37:26 -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 <0JL400F1DOYENJ00@brm-avmta-1.central.sun.com>; Fri, 13 Jul 2007 11:37:26 -0600 (MDT) Received: from jurassic.eng.sun.com ([129.146.228.50]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JL4009UKOYCLT40@brm-avmta-1.central.sun.com>; Fri, 13 Jul 2007 11:37:25 -0600 (MDT) Received: from tethys (tethys.SFBay.Sun.COM [129.146.226.92]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id l6DHbOHA388481; Fri, 13 Jul 2007 10:37:24 -0700 (PDT) Date: Fri, 13 Jul 2007 10:36:23 -0700 (PDT) From: Jerry Gilliam Subject: Re: 2007/402: Driver Periodic Timeouts To: eiji.ota@sun.com, Roch.Bourbonnais@sun.com Cc: Mark.Johnson@sun.com, Dan.Mick@sun.com, jg@jurassic.sfbay.sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, pl-direct@sun.com Reply-to: Jerry Gilliam Message-id: <200707131737.l6DHbOHA388481@jurassic.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_64 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: BVNjtgdj1LnqPjgbVCOAKg== X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 446 Folks, this is an active PSARC case; let's restrict comments to the proposal and discuss implementation details and conjecturing for what we'd like to see elsewhere. It's clear this proposal does not yet deliver everything we'd like but it does add value beyond what we presently have. None of the comments in the last few days have raised any objection to what's proposed and if that's correct, this case should be approved and closed. -jg From sacadmin Fri Jul 13 10:57:02 2007 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 l6DHv1DU016913 for ; Fri, 13 Jul 2007 10:57:02 -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 l6DHs8Px059898; Fri, 13 Jul 2007 11:54:10 -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 <0JL400I07PRQGZ00@nwk-avmta-2.sfbay.sun.com>; Fri, 13 Jul 2007 10:55:02 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JL400DDUPRO0Q60@nwk-avmta-2.sfbay.sun.com>; Fri, 13 Jul 2007 10:55:01 -0700 (PDT) Received: from d1-emea-10.sun.com (d1-emea-10.sun.com [192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6DHt0sQ017186; Fri, 13 Jul 2007 17:55:00 +0000 (GMT) Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JL400K01PP1ES00@d1-emea-10.sun.com> (original mail from Roch.Bourbonnais@Sun.COM); Fri, 13 Jul 2007 18:55:00 +0100 (BST) Received: from [192.168.1.2] ([86.211.142.81]) by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JL400HK4PRMZ12I@d1-emea-10.sun.com>; Fri, 13 Jul 2007 18:54:59 +0100 (BST) Date: Fri, 13 Jul 2007 19:56:26 +0200 From: Roch Bourbonnais Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <200707131737.l6DHbOHA388481@jurassic.eng.sun.com> Sender: Roch.Bourbonnais@sun.com To: Jerry Gilliam Cc: Eiji.Ota@sun.com, Mark.Johnson@sun.com, Dan.Mick@sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, pl-direct@sun.com Message-id: <81BA852B-D242-4438-98CA-31F833E9A79B@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) Content-type: text/plain; format=flowed; delsp=yes; charset=ISO-8859-1 X-PMX-Version: 5.2.0.264296 References: <200707131737.l6DHbOHA388481@jurassic.eng.sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by sac.sfbay.sun.com id l6DHv2DV016914 Status: RO Content-Length: 883 Le 13 juil. 07 à 19:36, Jerry Gilliam a écrit : > > Folks, this is an active PSARC case; let's restrict comments > to the proposal and discuss implementation details and > conjecturing for what we'd like to see elsewhere. It's > clear this proposal does not yet deliver everything we'd > like but it does add value beyond what we presently have. > None of the comments in the last few days have raised any > objection to what's proposed and if that's correct, this > case should be approved and closed. > > > -jg > Not correct. I object to the interface as stated because it gives the impression of delivering a hi-res callback but actually delivers 10ms base callbacks with lapses. We either need to say we round the requested interval to _10ms_. or state more clearly how the requested interval will be used to issue callbacks. That said, I am not a voting member. -r From sacadmin Fri Jul 13 11:05:37 2007 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 l6DI5anq017422 for ; Fri, 13 Jul 2007 11:05:36 -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 l6DI3OcF012585; Sat, 14 Jul 2007 02:03:25 +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 <0JL400H13Q5NFP00@brm-avmta-1.central.sun.com>; Fri, 13 Jul 2007 12:03:24 -0600 (MDT) Received: from jurassic.eng.sun.com ([129.146.226.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JL4009IUQ5ILV60@brm-avmta-1.central.sun.com>; Fri, 13 Jul 2007 12:03:19 -0600 (MDT) Received: from tethys (tethys.SFBay.Sun.COM [129.146.226.92]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id l6DI3FxO389223; Fri, 13 Jul 2007 11:03:15 -0700 (PDT) Date: Fri, 13 Jul 2007 11:02:14 -0700 (PDT) From: Jerry Gilliam Subject: Re: 2007/402: Driver Periodic Timeouts To: Roch.Bourbonnais@sun.com Cc: Eiji.Ota@sun.com, Mark.Johnson@sun.com, Dan.Mick@sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, pl-direct@sun.com Reply-to: Jerry Gilliam Message-id: <200707131803.l6DI3FxO389223@jurassic.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_64 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: mEPzmmgnjGTR0J6rorEQ8w== X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 483 > >Not correct. I object to the interface as stated because it >gives the impression of delivering a hi-res callback but actually >delivers 10ms base callbacks with lapses. > > We either need to say we round the requested interval to _10ms_. > >or state more clearly how the requested interval will be used to >issue callbacks. > We can document this, as has been suggested, and there have been a number of suggestions for the implementation to enforce this restriction. -jg From sacadmin Fri Jul 13 11:47:17 2007 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 l6DIlGpm018483 for ; Fri, 13 Jul 2007 11:47:16 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l6DIiqUI024848; Sat, 14 Jul 2007 02:45:04 +0800 (SGT) 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 <0JL400K0FS33V700@nwk-avmta-2.sfbay.sun.com>; Fri, 13 Jul 2007 11:45:03 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JL400DWBS330LB0@nwk-avmta-2.sfbay.sun.com>; Fri, 13 Jul 2007 11:45:03 -0700 (PDT) Received: from localhost (ota.SFBay.Sun.COM [129.146.226.183]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l6DIj2kA207753; Fri, 13 Jul 2007 11:45:03 -0700 (PDT) Date: Fri, 13 Jul 2007 11:45:01 -0700 (PDT) From: eiji.ota@sun.com Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <200707131803.l6DI3FxO389223@jurassic.eng.sun.com> Sender: Eiji Ota To: jg@jurassic.sfbay.sun.com Cc: Roch.Bourbonnais@sun.com, Mark.Johnson@sun.com, Dan.Mick@sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, pl-direct@sun.com Message-id: <20070713114501P.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.2.0.264296 Lines: 38 References: <200707131803.l6DI3FxO389223@jurassic.eng.sun.com> X-Dispatcher: imput version 20000228(IM140) Status: RO Content-Length: 1237 > > > >Not correct. I object to the interface as stated because it > >gives the impression of delivering a hi-res callback but actually > >delivers 10ms base callbacks with lapses. > > > > We either need to say we round the requested interval to _10ms_. > > > >or state more clearly how the requested interval will be used to > >issue callbacks. > > > > We can document this, as has been suggested, and there have been > a number of suggestions for the implementation to enforce this > restriction. Yes, actually how much error depends on the system resolution in addition to other factors (e.g. interrupt handler overhead, etc.), and you can see an error of ab. 10ms or 1ms every time you request. So I state more clearly how the requested interval will be treated in the document. e.g. ddi_periodic_t ddi_periodic_add(void (*func)(void *), void *arg, hrtime_t interval, int level) PARAMETERS interval: interval time in nanoseconds How this interval is treated depends on the clock resolution on the system. Time when a function is invoked can have an error from the resolution and the exact time in which the function is invoked is rather closer to the approximation. Cheers, -Eiji From sacadmin Fri Jul 13 11:49:52 2007 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 l6DInpr6018532 for ; Fri, 13 Jul 2007 11:49:52 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l6DIljRJ025962; Sat, 14 Jul 2007 02:47:48 +0800 (SGT) 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 <0JL400K0PS7MZF00@nwk-avmta-2.sfbay.sun.com>; Fri, 13 Jul 2007 11:47:46 -0700 (PDT) Received: from engmail4sca.SFBay.Sun.COM ([129.145.155.74]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JL400D38S7K0TB0@nwk-avmta-2.sfbay.sun.com>; Fri, 13 Jul 2007 11:47:45 -0700 (PDT) Received: from grimmy.eng.sun.com (grimmy.SFBay.Sun.COM [129.146.108.114]) by engmail4sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l6DIlg5a012310; Fri, 13 Jul 2007 11:47:42 -0700 (PDT) Received: from grimmy.eng.sun.com (localhost [127.0.0.1]) by grimmy.eng.sun.com (8.12.10+Sun/8.12.10) with ESMTP id l6DIleQt012134; Fri, 13 Jul 2007 11:47:40 -0700 (PDT) Received: from localhost (randyf@localhost) by grimmy.eng.sun.com (8.12.10+Sun/8.12.10/Submit) with ESMTP id l6DIleSB012130; Fri, 13 Jul 2007 11:47:40 -0700 (PDT) Date: Fri, 13 Jul 2007 11:47:40 -0700 (PDT) From: Randy Fishel Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <81BA852B-D242-4438-98CA-31F833E9A79B@Sun.COM> X-X-Sender: randyf@grimmy To: Roch Bourbonnais Cc: Jerry Gilliam , Eiji.Ota@sun.com, Mark.Johnson@sun.com, Dan.Mick@sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, pl-direct@sun.com Message-id: Content-id: MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_KWkZ1fUP+JuGd6ldvh4nng)" X-PMX-Version: 5.2.0.264296 References: <200707131737.l6DHbOHA388481@jurassic.eng.sun.com> <81BA852B-D242-4438-98CA-31F833E9A79B@Sun.COM> X-Authentication-warning: grimmy.eng.sun.com: randyf owned process doing -bs Status: RO Content-Length: 2042 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --Boundary_(ID_KWkZ1fUP+JuGd6ldvh4nng) Content-id: Content-type: TEXT/PLAIN; CHARSET=X-UNKNOWN Content-transfer-encoding: QUOTED-PRINTABLE On Fri, 13 Jul 2007, Roch Bourbonnais wrote: >=20 > Le 13 juil. 07 =E0 19:36, Jerry Gilliam a =E9crit : >=20 > >=20 > > Folks, this is an active PSARC case; let's restrict comments > > to the proposal and discuss implementation details and > > conjecturing for what we'd like to see elsewhere. It's > > clear this proposal does not yet deliver everything we'd > > like but it does add value beyond what we presently have. > > None of the comments in the last few days have raised any > > objection to what's proposed and if that's correct, this > > case should be approved and closed. > >=20 > >=20 > > -jg > >=20 >=20 > Not correct. I object to the interface as stated because it > gives the impression of delivering a hi-res callback but actually > delivers 10ms base callbacks with lapses. >=20 > =09We either need to say we round the requested interval to _10ms_. >=20 > or state more clearly how the requested interval will be used to issue > callbacks. >=20 > That said, I am not a voting member. >=20 > -r >=20 And I objected, as it doesn't look to me that this has accounted=20 well enough for CPR/DR, instead claiming that this is the way it works=20 in timeout(9f). In the case of cyclic_add() (which several drivers=20 are doing), if there were a suspend, sleep, or some other "don't call=20 me till I restore, but remember my configuration" facility, it would=20 be much easier for driver writers to understand the problem (or else,=20 make sure that the documentation is clear about what drivers should do=20 with periodics when the driver is asked to suspend/DR). But also like Roch, I don't get to vote, just to comment. =09---- Randy= --Boundary_(ID_KWkZ1fUP+JuGd6ldvh4nng)-- From sacadmin Fri Jul 13 11:57:59 2007 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 l6DIvw6O019165 for ; Fri, 13 Jul 2007 11:57:58 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l6DIthJK028102; Sat, 14 Jul 2007 02:55:46 +0800 (SGT) 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 <0JL400L15SKWA800@nwk-avmta-2.sfbay.sun.com>; Fri, 13 Jul 2007 11:55:44 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JL400D5TSKW0UA0@nwk-avmta-2.sfbay.sun.com>; Fri, 13 Jul 2007 11:55:44 -0700 (PDT) Received: from localhost (ota.SFBay.Sun.COM [129.146.226.183]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l6DIthV2210454; Fri, 13 Jul 2007 11:55:43 -0700 (PDT) Date: Fri, 13 Jul 2007 11:55:42 -0700 (PDT) From: eiji.ota@sun.com Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: Sender: Eiji Ota To: randy.fishel@sun.com Cc: Roch.Bourbonnais@sun.com, jg@jurassic.sfbay.sun.com, Mark.Johnson@sun.com, dan.mick@sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, pl-direct@sun.com Message-id: <20070713115542T.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.2.0.264296 Lines: 58 References: <200707131737.l6DHbOHA388481@jurassic.eng.sun.com> <81BA852B-D242-4438-98CA-31F833E9A79B@Sun.COM> X-Dispatcher: imput version 20000228(IM140) Status: RO Content-Length: 2213 > > > > > > Folks, this is an active PSARC case; let's restrict comments > > > to the proposal and discuss implementation details and > > > conjecturing for what we'd like to see elsewhere. It's > > > clear this proposal does not yet deliver everything we'd > > > like but it does add value beyond what we presently have. > > > None of the comments in the last few days have raised any > > > objection to what's proposed and if that's correct, this > > > case should be approved and closed. > > > > > > > > > -jg > > > > > > > Not correct. I object to the interface as stated because it > > gives the impression of delivering a hi-res callback but actually > > delivers 10ms base callbacks with lapses. > > > > We either need to say we round the requested interval to _10ms_. > > > > or state more clearly how the requested interval will be used to issue > > callbacks. > > > > That said, I am not a voting member. > > > > -r > > And I objected, as it doesn't look to me that this has accounted > well enough for CPR/DR, instead claiming that this is the way it works > in timeout(9f). In the case of cyclic_add() (which several drivers > are doing), if there were a suspend, sleep, or some other "don't call > me till I restore, but remember my configuration" facility, it would > be much easier for driver writers to understand the problem (or else, > make sure that the documentation is clear about what drivers should do > with periodics when the driver is asked to suspend/DR). > > But also like Roch, I don't get to vote, just to comment. Hi Randy, My previous explanation seems not enough, if so, I'm sorry. So far there is a way to protect your request during the suspend-resume, which is employed by timeout(9F) and cpr(). The proposed interface uses the same mechanism to keep away from a panic and/or a hang though this is the implementation. During my test (by cpr and kmdb), I couldn't observe any problems, so I think this mechanism is so far sufficient to guard it. Frankly speaking when I heard about the problem, I was confused. If there is, it would be a Solaris bug which should be corrected from the different angle. hope this would be helpful. Cheers, -Eiji From sacadmin Fri Jul 13 13:21:14 2007 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 l6DKLELt022731 for ; Fri, 13 Jul 2007 13:21:14 -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 l6DKIKEj007087; Fri, 13 Jul 2007 13:18:24 -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 <0JL400209WELIZ00@nwk-avmta-2.sfbay.sun.com>; Fri, 13 Jul 2007 13:18:21 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.104.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JL400DC2WEL0QD0@nwk-avmta-2.sfbay.sun.com>; Fri, 13 Jul 2007 13:18:21 -0700 (PDT) Received: from grimmy.eng.sun.com (grimmy.SFBay.Sun.COM [129.146.108.114]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id l6DKIAlY395021; Fri, 13 Jul 2007 13:18:10 -0700 (PDT) Date: Fri, 13 Jul 2007 13:18:09 -0700 (PDT) From: Randy Fishel Subject: Re: 2007/402: Driver Periodic Timeouts To: Eiji.Ota@sun.com, jg@jurassic.sfbay.sun.com Cc: Mark.Johnson@sun.com, Dan.Mick@sun.com, psarc@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, pl-direct@sun.com Reply-to: Randy Fishel Message-id: <200707132018.l6DKIAlY395021@jurassic.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_48 SunOS 5.10 sun4u sparc Content-type: text/PLAIN Content-transfer-encoding: 7BIT X-Sun-Text-type: ascii X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 864 > > And I objected, as it doesn't look to me that this has accounted > well enough for CPR/DR, instead claiming that this is the way it works > in timeout(9f). In the case of cyclic_add() (which several drivers > are doing), if there were a suspend, sleep, or some other "don't call > me till I restore, but remember my configuration" facility, it would > be much easier for driver writers to understand the problem (or else, > make sure that the documentation is clear about what drivers should do > with periodics when the driver is asked to suspend/DR). > > But also like Roch, I don't get to vote, just to comment. > > > ---- Randy After a bit of conversation with the submitter, I am comfortable that my issues can be resolved in documentation (some of which will come from me when I get suspend/resume _really_ integrated). ---- Randy From sacadmin Tue Jul 17 13:39:05 2007 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 l6HKd4Yt029666 for ; Tue, 17 Jul 2007 13:39:04 -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 l6HKangV029479; Wed, 18 Jul 2007 04:36:52 +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 <0JLC00E0NBXDAJ00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 17 Jul 2007 13:36:49 -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 <0JLC00G8PBX5VYF0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 17 Jul 2007 13:36:41 -0700 (PDT) Received: from localhost (ota.SFBay.Sun.COM [129.146.226.183]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l6HKae1U679699; Tue, 17 Jul 2007 13:36:41 -0700 (PDT) Date: Tue, 17 Jul 2007 13:36:40 -0700 (PDT) From: eiji.ota@sun.com Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <18069.57854.546654.836409@gargle.gargle.HOWL> Sender: Eiji Ota To: psarc@sun.com Cc: Dan.Mick@sun.com, jg@jurassic.sfbay.sun.com, Roch.Bourbonnais@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, pl-direct@sun.com Message-id: <20070717133640A.eota@sun.com> MIME-version: 1.0 X-Mailer: Mew version 1.94.2 on XEmacs 21.1 (Cuyahoga Valley) Content-type: multipart/mixed; boundary="Boundary_(ID_Kk016qOD64mXAT+IcKEzZw)" X-PMX-Version: 5.2.0.264296 Lines: 158 References: <20070711080800U.eota@sun.com> <20070711081257T.eota@sun.com> <18069.57854.546654.836409@gargle.gargle.HOWL> X-Dispatcher: imput version 20000228(IM140) Status: RO Content-Length: 7387 --Boundary_(ID_Kk016qOD64mXAT+IcKEzZw) Content-type: Text/Plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi all, I've worked out with Roch, Mark and Jerry on my PSARC case for the last few days, and the things remained were all solved. Now I'm happy to attach the updated proposal (man page part), which is the output from our work. I'd like to say "thank you" to all helping me this time. Without your helps, I couldn't deal with this.. Cheers, -Eiji --Boundary_(ID_Kk016qOD64mXAT+IcKEzZw) Content-type: Text/Plain; NAME=updated_manpages.txt; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=updated_manpages.txt 8. Document 8.1. ddi_periodic_add(9F) Kernel Functions for Drivers ddi_periodic_add(9F) NAME ddi_periodic_add - issue nanosecond periodic timeout requests SYNOPSIS #include #include ddi_periodic_t ddi_periodic_add(void (*func)(void *), void *arg, hrtime_t interval, int level) INTERFACE LEVEL Solaris DDI specific (Solaris DDI) PARAMETERS func: the callback function The callback function will be invoked periodically in the specified interval. The function is invoked in kernel context if the argument level is zero. Otherwise it's invoked in interrupt context at the specified level. arg: the argument passed to the callback function interval: interval time in nanoseconds level : callback interrupt level If the value is zero, the callback function is invoked in kernel context. If the value is more than zero, but less than or equal to ten, the callback function is invoked in interrupt context at the specified interrupt level, which may be used for real time applications. This value must be in range of 0-10. DESCRIPTION ddi_periodic_add(9F) schedules the specified function to be periodically invoked in the nanosecond interval time. As well as timeout(9F), the exact time interval over which the function takes effect cannot be guaranteed, but the value given is a close approximation. RETURN VALUES ddi_periodic_add(9F) returns the non-zero opaque value (ddi_periodic_t), which might be used for ddi_periodic_delete(9F) to specify the request. CONTEXT ddi_periodic_add(9F) can be called in user or kernel context, but it cannot be called in interrupt context, which is different from timeout(9F). EXAMPLES Example 1: Using ddi_periodic_add(9F) for a callback function invoked in kernel context. In the following example, the device driver registers a periodic callback function invoked in kernel context. static void my_periodic_func(void *arg) { /* * This handler is invoked periodically. */ struct my_state *statep = (struct my_state *)arg; mutex_enter(&statep->lock); if (load_unbalanced(statep)) { balance_tasks(statep); } mutex_exit(&statep->lock); } static void start_periodic_timer(struct my_state *statep) { hrtime_t interval = CHECK_INTERVAL; /* * Register my_callback which is invoked periodically * in CHECK_INTERVAL in kernel context. */ statep->periodic_id = ddi_periodic_add(my_periodic_func, statep, interval, 0); } Example 2: Using ddi_periodic_add(9F) for a callback function periodically invoked in interrupt context at level 7. In the following example, the device driver registers a callback function invoked in interrupt context at level 7. /* * This handler is invoked periodically in interrupt context. */ static void my_periodic_int7_func(void *arg) { struct my_state *statep = (struct my_state *)arg; mutex_enter(&statep->lock); monitor_device(statep); mutex_exit(&statep->lock); } static void start_monitor_device(struct my_state *statep) { hrtime_t interval = MONITOR_INTERVAL; /* * Register the callback function invoked periodically * at interrupt level 7. */ statep->periodic_id = ddi_periodic_add(my_periodic_int7_func, statep, interval, 7); } NOTES The interval a caller may specify must be an integral multiple of 10ms. No other values are supported at this time. The interval specified is a lower bound on the interval on which the callback occurs. SEE ALSO ddi_periodic_delete(9F), timeout(9F), untimeout(9F), qtimeout(9F), quntimeout(9F), cv_timedwait(9F), delay(9F), drv_usectohz(9F) 8.2. ddi_periodic_delete(9F) Kernel Functions for Drivers ddi_periodic_delete(9F) NAME ddi_periodic_delete - cancel nanosecond periodic timeout requests SYNOPSIS #include #include void ddi_periodic_delete(ddi_periodic_t req) INTERFACE LEVEL Solaris DDI specific (Solaris DDI) PARAMETERS req: ddi_periodic_t opaque value ddi_periodic_add(9F) returned previously. DESCRIPTION ddi_periodic_delete(9F) cancels the ddi_periodic_add(9F) request previously issued. As well as untimeout(9F), calling ddi_periodic_delete(9F) against a periodic timeout request which is either running on another CPU, or has already canceled causes no problems. Unlike untimeout(9F), there is no restrictions on the lock which might be held across the call to ddi_periodic_delete(9F). CONTEXT ddi_periodic_delete(9F) can be called in user or kernel context, but it cannot be called in interrupt context, which is different from untimeout(9F). EXAMPLES In the following example, the device driver cancels the timeout request by calling ddi_periodic_delete() against the request previously issued. /* * Stop the periodic timer */ static void stop_periodic_timer(struct my_state *statep) { ddi_periodic_delete(statep->periodic_id); } static void start_periodic_timer(struct my_state *statep) { hrtime_t interval = CHECK_INTERVAL; /* * Register my_callback which is invoked periodically * in CHECK_INTERVAL in kernel context. */ statep->periodic_id = ddi_periodic_add(my_periodic_func, statep, interval, 0); } static void my_periodic_func(void *arg) { /* * This handler is invoked periodically. */ struct my_state *statep = (struct my_state *)arg; mutex_enter(&statep->lock); if (load_unbalanced(statep)) { balance_tasks(statep); } mutex_exit(&statep->lock); } SEE ALSO ddi_periodic_add(9F), timeout(9F), untimeout(9F), qtimeout(9F), quntimeout(9F), cv_timedwait(9F), delay(9F), drv_usectohz(9F) --Boundary_(ID_Kk016qOD64mXAT+IcKEzZw)-- From sacadmin Tue Jul 17 13:49:06 2007 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 l6HKn5N4000106 for ; Tue, 17 Jul 2007 13:49:05 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l6HKkndO024620; Tue, 17 Jul 2007 21:46:56 +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 <0JLC00K01CE8T600@nwk-avmta-2.sfbay.sun.com>; Tue, 17 Jul 2007 13:46:56 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.68.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JLC00IY2CE85340@nwk-avmta-2.sfbay.sun.com>; Tue, 17 Jul 2007 13:46:56 -0700 (PDT) Received: from tethys (tethys.SFBay.Sun.COM [129.146.226.92]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id l6HKkr1B677609; Tue, 17 Jul 2007 13:46:55 -0700 (PDT) Date: Tue, 17 Jul 2007 13:45:51 -0700 (PDT) From: Jerry Gilliam Subject: Re: 2007/402: Driver Periodic Timeouts To: eiji.ota@sun.com, psarc@sun.com Cc: Dan.Mick@sun.com, jg@jurassic.sfbay.sun.com, Roch.Bourbonnais@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, pl-direct@sun.com Reply-to: Jerry Gilliam Message-id: <200707172046.l6HKkr1B677609@jurassic.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_64 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: iBTfOOrBl108ILNsbIZFQw== X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 110 With closure on all issues and with the updated man page, I am marking this case as closed, approved. -jg From sacadmin Wed Jul 18 00:00:27 2007 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 l6I70QLs013040 for ; Wed, 18 Jul 2007 00:00:27 -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 l6I6wEgg001639; Wed, 18 Jul 2007 14:58:18 +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 <0JLD003134P3U100@brm-avmta-1.central.sun.com>; Wed, 18 Jul 2007 00:58:15 -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 <0JLD005RF4P38PE0@brm-avmta-1.central.sun.com>; Wed, 18 Jul 2007 00:58:15 -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 l6I6wE6f019649; Tue, 17 Jul 2007 23:58:14 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JLD00N014IL4C00@fe-sfbay-10.sun.com> (original mail from Garrett.Damore@Sun.COM); Tue, 17 Jul 2007 23:58:14 -0700 (PDT) Received: from [192.168.251.21] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JLD00D2S4P2FR40@fe-sfbay-10.sun.com>; Tue, 17 Jul 2007 23:58:14 -0700 (PDT) Date: Tue, 17 Jul 2007 23:55:04 -0700 From: "Garrett D'Amore" Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <20070717133640A.eota@sun.com> Sender: Garrett.Damore@sun.com To: Eiji.Ota@sun.com Cc: psarc@sun.com, Dan.Mick@sun.com, jg@jurassic.sfbay.sun.com, Roch.Bourbonnais@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, pl-direct@sun.com Message-id: <469DB948.9010606@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070711080800U.eota@sun.com> <20070711081257T.eota@sun.com> <18069.57854.546654.836409@gargle.gargle.HOWL> <20070717133640A.eota@sun.com> User-Agent: Thunderbird 2.0.0.0 (X11/20070618) Status: RO Content-Length: 841 Eiji.Ota@Sun.COM wrote: > Hi all, > > I've worked out with Roch, Mark and Jerry on my PSARC case for the last > few days, and the things remained were all solved. > > Now I'm happy to attach the updated proposal (man page part), which > is the output from our work. I'd like to say "thank you" to all helping me > this time. Without your helps, I couldn't deal with this.. > > Cheers, > > -Eiji > > > Hmmm.... now reading this I see that the interrupt level is provided as an integer 1-10. That bothers me slightly. How does it relate to interrupt levels used by the DDI interrupt framework? And levels used with interrupt block cookies, etc.? Is this the same kind of priority level returned by ddi_intr_get_pri()? If so, can we *say* that in the man page? (And that it can be used to initialize locks, etc.?) -- Garrett From sacadmin Wed Jul 18 04:31:33 2007 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 l6IBVXSN019029 for ; Wed, 18 Jul 2007 04:31:33 -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 l6IBTSKf017623; Wed, 18 Jul 2007 04:29:29 -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 <0JLD00H07H95H300@nwk-avmta-2.sfbay.sun.com>; Wed, 18 Jul 2007 04:29:29 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JLD007YNH942N70@nwk-avmta-2.sfbay.sun.com>; Wed, 18 Jul 2007 04:29:28 -0700 (PDT) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6IBTSgk010555; Wed, 18 Jul 2007 11:29:28 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JLD00901H1T2S00@mail-amer.sun.com> (original mail from Mark.Johnson@Sun.COM); Wed, 18 Jul 2007 05:29:27 -0600 (MDT) Received: from mrj.local ([75.68.54.173]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JLD00CW8H92GTM2@mail-amer.sun.com>; Wed, 18 Jul 2007 05:29:27 -0600 (MDT) Date: Wed, 18 Jul 2007 07:31:00 -0400 From: Mark Johnson Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <469DB948.9010606@sun.com> Sender: Mark.Johnson@sun.com To: "Garrett D'Amore" Cc: Eiji.Ota@sun.com, psarc@sun.com, Dan.Mick@sun.com, jg@jurassic.sfbay.sun.com, Roch.Bourbonnais@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, pl-direct@sun.com Message-id: <469DF9F4.3090707@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20070711080800U.eota@sun.com> <20070711081257T.eota@sun.com> <18069.57854.546654.836409@gargle.gargle.HOWL> <20070717133640A.eota@sun.com> <469DB948.9010606@sun.com> User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) Status: RO Content-Length: 1441 Garrett D'Amore wrote: > Eiji.Ota@Sun.COM wrote: >> Hi all, >> >> I've worked out with Roch, Mark and Jerry on my PSARC case for the last >> few days, and the things remained were all solved. >> >> Now I'm happy to attach the updated proposal (man page part), which >> is the output from our work. I'd like to say "thank you" to all >> helping me >> this time. Without your helps, I couldn't deal with this.. >> >> Cheers, >> >> -Eiji >> >> >> > Hmmm.... now reading this I see that the interrupt level is provided as > an integer 1-10. > > That bothers me slightly. How does it relate to interrupt levels used > by the DDI interrupt framework? I had the same reaction at first. :-) The "new" interrupt framework exposes "interrupt levels". e.g. ddi_intr_add_softint(9F) > And levels used with interrupt block > cookies, etc.? Is this the same kind of priority level returned by > ddi_intr_get_pri()? If so, can we *say* that in the man page? (And > that it can be used to initialize locks, etc.?) I agree. The examples in the man page should include the initialization of the mutex. The man page should also reference ddi_intr_get_pri/ddi_intr_set_pri e.g. statep->periodic_id = ddi_periodic_add(my_periodic_int7_func, statep, interval, 7); mutex_init(&my_mutex, NULL, MUTEX_DRIVER, DDI_INTR_PRI(7)); MRJ -- Mark Johnson Sun Microsystems, Inc. (781) 442-0869 From sacadmin Wed Jul 18 11:21:23 2007 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 l6IILMWa028535 for ; Wed, 18 Jul 2007 11:21:23 -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 l6III1P5023606; Thu, 19 Jul 2007 02:18:02 +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 <0JLE0040B060SF00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 18 Jul 2007 11:18:00 -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 <0JLE001QS05Y1940@nwk-avmta-1.sfbay.Sun.COM>; Wed, 18 Jul 2007 11:17:58 -0700 (PDT) Received: from localhost (ota.SFBay.Sun.COM [129.146.226.183]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l6IIHvDR856838; Wed, 18 Jul 2007 11:17:57 -0700 (PDT) Date: Wed, 18 Jul 2007 11:17:55 -0700 (PDT) From: eiji.ota@sun.com Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <469DF9F4.3090707@sun.com> Sender: Eiji Ota To: Mark.Johnson@sun.com Cc: Garrett.Damore@sun.com, psarc@sun.com, Dan.Mick@sun.com, jg@jurassic.sfbay.sun.com, Roch.Bourbonnais@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, pl-direct@sun.com Message-id: <20070718111755E.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.2.0.264296 Lines: 52 References: <20070717133640A.eota@sun.com> <469DB948.9010606@sun.com> <469DF9F4.3090707@sun.com> X-Dispatcher: imput version 20000228(IM140) Status: RO Content-Length: 1855 Hi, > >> Hi all, > >> > >> I've worked out with Roch, Mark and Jerry on my PSARC case for the last > >> few days, and the things remained were all solved. > >> > >> Now I'm happy to attach the updated proposal (man page part), which > >> is the output from our work. I'd like to say "thank you" to all > >> helping me > >> this time. Without your helps, I couldn't deal with this.. > >> > >> Cheers, > >> > >> -Eiji > >> > >> > >> > > Hmmm.... now reading this I see that the interrupt level is provided as > > an integer 1-10. > > > > That bothers me slightly. How does it relate to interrupt levels used > > by the DDI interrupt framework? > > I had the same reaction at first. :-) The "new" interrupt framework exposes > "interrupt levels". e.g. ddi_intr_add_softint(9F) Yes, we had some discussion about it before PSARC; the initial proposal used a macro (representing a certain interrupt such as LOW, MED, HIGH interrupts) not an integer, and we considered the platform dependency (on SPARC or X86), but seeing devices such as IBs, it would be difficult to represent interrupt levels in that way and the conclusion was using an integer directly in the end. > > And levels used with interrupt block > > cookies, etc.? Is this the same kind of priority level returned by > > ddi_intr_get_pri()? If so, can we *say* that in the man page? (And > > that it can be used to initialize locks, etc.?) > > I agree. The examples in the man page should include the initialization > of the mutex. The man page should also reference > ddi_intr_get_pri/ddi_intr_set_pri > > e.g. > statep->periodic_id = ddi_periodic_add(my_periodic_int7_func, > statep, interval, 7); > mutex_init(&my_mutex, NULL, MUTEX_DRIVER, DDI_INTR_PRI(7)); Right. I'll correct it as you suggested here. Thank you for your suggestion. -Eiji From sacadmin Wed Jul 18 11:34:48 2007 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 l6IIYlWh028712 for ; Wed, 18 Jul 2007 11:34:47 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l6IIWMe0024538; Wed, 18 Jul 2007 19:32:36 +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 <0JLE00K2J0UAV400@brm-avmta-1.central.sun.com>; Wed, 18 Jul 2007 12:32:34 -0600 (MDT) Received: from jurassic.eng.sun.com ([129.146.68.130]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JLE00HTH0U8FP30@brm-avmta-1.central.sun.com>; Wed, 18 Jul 2007 12:32:32 -0600 (MDT) Received: from grimmy.eng.sun.com (grimmy.SFBay.Sun.COM [129.146.108.114]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id l6IIWVEU746790; Wed, 18 Jul 2007 11:32:31 -0700 (PDT) Date: Wed, 18 Jul 2007 11:32:27 -0700 (PDT) From: Randy Fishel Subject: Re: 2007/402: Driver Periodic Timeouts To: Mark.Johnson@sun.com, eiji.ota@sun.com Cc: Garrett.Damore@sun.com, psarc@sun.com, Dan.Mick@sun.com, jg@jurassic.sfbay.sun.com, Roch.Bourbonnais@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, pl-direct@sun.com Reply-to: Randy Fishel Message-id: <200707181832.l6IIWVEU746790@jurassic.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_48 SunOS 5.10 sun4u sparc Content-type: text/PLAIN Content-transfer-encoding: 7BIT X-Sun-Text-type: ascii X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 309 I think that there can be usefull input to the project team that doesn't need to be either included in the case file, or sent to a large (mostly uninterested) list. Is there a developer/interest list that people can subscribe to and follow or contribute to the development of this feature? ---- Randy From sacadmin Wed Jul 18 12:14:16 2007 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 l6IJEGFC000243 for ; Wed, 18 Jul 2007 12:14:16 -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 l6IJC7Oe005757; Wed, 18 Jul 2007 12:12:09 -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 <0JLE00A0X2O81G00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 18 Jul 2007 12:12:08 -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 <0JLE001K12O819B0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 18 Jul 2007 12:12:08 -0700 (PDT) Received: from localhost (ota.SFBay.Sun.COM [129.146.226.183]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l6IJC7tP877633; Wed, 18 Jul 2007 12:12:07 -0700 (PDT) Date: Wed, 18 Jul 2007 12:12:06 -0700 (PDT) From: eiji.ota@sun.com Subject: Re: 2007/402: Driver Periodic Timeouts In-reply-to: <200707181832.l6IIWVEU746790@jurassic.eng.sun.com> Sender: Eiji Ota To: randyf@jurassic.eng.sun.com Cc: Mark.Johnson@sun.com, Garrett.Damore@sun.com, psarc@sun.com, Dan.Mick@sun.com, jg@jurassic.sfbay.sun.com, Roch.Bourbonnais@sun.com, Wesley.Shao@sun.com, Shidokht.Yadegari@sun.com, Bryan.Cantrill@sun.com, Sunay.Tripathi@sun.com, pl-direct@sun.com Message-id: <20070718121206W.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.2.0.264296 Lines: 17 References: <200707181832.l6IIWVEU746790@jurassic.eng.sun.com> X-Dispatcher: imput version 20000228(IM140) Status: RO Content-Length: 628 Hi Randy, > > I think that there can be usefull input to the project team that > doesn't need to be either included in the case file, or sent to a large > (mostly uninterested) list. Is there a developer/interest list that > people can subscribe to and follow or contribute to the development of > this feature? > The interrupt level issue was discussed in ddi-iteam and ddi-drivers from December to February, so you should find the discussion there, but unfortunately the project didn't have its own mailing list and I made new_timeout@sun.com for the future work after I saw your e-mail. (it was born just now). -Eiji