From gd78059@sac.sfbay.sun.com Tue May 27 11:34:53 2008 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 m4RIYr9U026288 for ; Tue, 27 May 2008 11:34:53 -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 m4RIYro5000930; Tue, 27 May 2008 11:34:53 -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 <0K1J00H01IA5BE00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 27 May 2008 11:34:53 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1J00IH7IA5SB50@nwk-avmta-1.sfbay.Sun.COM>; Tue, 27 May 2008 11:34:53 -0700 (PDT) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m4RIYq07013587; Tue, 27 May 2008 11:34:52 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m4RIYpLe026283; Tue, 27 May 2008 11:34:51 -0700 (PDT) Received: (from gd78059@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m4RIYpXT026279; Tue, 27 May 2008 11:34:51 -0700 (PDT) Date: Tue, 27 May 2008 11:34:51 -0700 (PDT) From: "Garrett D'Amore - sun microsystems" Subject: PCI Multimedia Class Interrupt Priorities [PSARC/2008/343 FastTrack timeout 06/03/2008] To: PSARC-ext@sun.com Cc: Garrett.Damore@sun.com Message-id: <200805271834.m4RIYpXT026279@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 2405 I'm submitting this fast-track case on my own behalf. It probably could qualify for self-review, but I want to give any interested parties a chance to comment. Requested binding is Patch on the basis that no real interfaces are changing, although realistically there is probaby little chance that we'll backport this to S10. Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: PCI Multimedia Class Interrupt Priorities 1.2. Name of Document Author/Supplier: Author: Garrett D'Amore 1.3 Date of This Document: 27 May, 2008 4. Technical Description Fast-track: PCI Multimedia Class Interrupt Priorities Requested Binding: Patch Problem ------- The current Solaris PCI nexus logic assigns high level interrupts (level 12) to devices that are in PCI class 4 (multimedia class). This includes all audio devices. (Most of which are either subclass 1 for legacy audio devices, or 3 for newer hdaudio compliant devices.) However, none of the current Solaris device drivers can operate with such high interrupt priorities. All of the audio drivers in Solaris wind up reassigning an interrupt priority of 9 using the undocumented property "interrupt-priorities" in their driver.conf(4) to overcome this problem. (Recall that priority 10 is "lock level", the level above which device drivers must not use locks or other constructs which could result in putting a thread to sleep.) The project team is unaware of device drivers for any hardware in the multimedia class *other* than audio devices. The new audio framework proposed in PSARC 2008/318 will also be unable to function with high-level interrupts. Solution -------- We propose to change the default interrupt-priority for all devices in the multimedia class (PCI class 4) to 9. Experience has shown that this level is sufficiently high to meet the needs of low-latency audio devices, without requiring extraordinary measures normally required when dealing with high-level interrupts. As indicated, we are unaware of any devices supported by Solaris that are in the multimedia class other than those associated with audio support. 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 gdamore@sun.com Wed May 28 13:12:21 2008 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 m4SKCLQZ019337 for ; Wed, 28 May 2008 13:12:21 -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 m4SKCKsm027198 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 28 May 2008 13:12:21 -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 <0K1L00L03HGLCT00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 May 2008 14:12:21 -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 <0K1L005AJHGKD3C0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 May 2008 14:12:20 -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 m4SKCKps012095 for ; Wed, 28 May 2008 13:12:20 -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 <0K1L00401H1P2A00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 May 2008 13:12:20 -0700 (PDT) Received: from [192.168.251.106] ([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 <0K1L00CA5HG5I1G0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 May 2008 13:12:05 -0700 (PDT) Date: Wed, 28 May 2008 13:04:59 -0700 From: "Garrett D'Amore" Subject: [Fwd: Re: PCI Multimedia Class Interrupt Priorities [PSARC/2008/343 FastTrack timeout 06/03/2008]] Sender: Garrett.Damore@sun.com To: PSARC-ext , Wesley Shao Message-id: <483DBAEB.3000400@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_zWT9L/3Rda+WMOqNnj61zw)" X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 6155 This is a multi-part message in MIME format. --Boundary_(ID_zWT9L/3Rda+WMOqNnj61zw) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Resending, since I forgot to add the CC to PSARC! Doh! --Boundary_(ID_zWT9L/3Rda+WMOqNnj61zw) Content-type: message/rfc822; name="Re: PCI Multimedia Class Interrupt Priorities [PSARC/2008/343 FastTrack timeout06/03/2008].eml" Date: Wed, 28 May 2008 13:04:06 -0700 From: Garrett D'Amore Subject: Re: PCI Multimedia Class Interrupt Priorities [PSARC/2008/343 FastTrack timeout 06/03/2008] In-reply-to: <483DBAD3.9010609@sun.com> To: Wesley Shao Message-id: <483DBAB6.4010407@sun.com> X-Envelope-from: gdamore@sun.com X-Envelope-to: PSARC-ext <@smarthost.sun.com:PSARC-ext@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200805271834.m4RIYpXT026279@sac.sfbay.sun.com> <483D0251.2050104@sun.com> <483D7320.2090001@sun.com> <483DBAD3.9010609@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Wesley Shao wrote: > I can't think of reasons for below audio and above networking. Modern > audio devices (especially the HD ones) are all DMA based, interrupt > priority becomes relatively less important. I would like to push for 7 > if we can. Why? (I can't think of reasons either, but then again I can't think of reasons for between audio and lock level.) Put another way, I'm not sure we buy anything by further reducing the level below 8. I can definitely think of good reasons why even with DMA, interrupts needs to be serviced in a timely fashion. (Synchronization of audio with video, games, etc. as one example. Certain kinds of low latency applications such as echo cancellation, and VoIP processing, are other examples where one wants to make sure that the processing latency is as low as we can easily make it.) Btw, I'm putting PSARC back on the distribution list for this, as this discussion really needs to be recorded in the case log. At ARC today, this case was approved for level 8. Its probably a minor update if we think we should move to level 7, but I am a bit more hesitant there, given the need for audio drivers to get serviced promptly. -- Garrett > > Wes > > Garrett D'Amore wrote: >> Wesley Shao wrote: >>> Why not making it even lower, like 7 or 8? There are virtually no >>> drivers >>> using 7 or higher. That will give some breathing room in case we >>> have to >>> debug some drivers and want to put them between audio and 10. >> >> I'm open to this idea. Level 9 was what was already in use, and >> seemed to be well tested, which is why I proposed it. But I'd be >> happy to use 8, as well. I don't think audio drivers have any >> dependencies on any other drivers/devices, apart from typical >> lock-oriented dependencies upon the system timer. >> >> Using 8 allows 7 to be used for things that are "just below" audio, >> and 9 to be used for things that are "just above". (I can't think of >> any examples of either one of those... but maybe someday someone else >> will.) >> >> Does anyone else have any thoughts? >> >> -- Garrett >>> >>> Wes >>> >>> Garrett D'Amore - sun microsystems wrote: >>>> I'm submitting this fast-track case on my own behalf. It probably >>>> could >>>> qualify for self-review, but I want to give any interested parties >>>> a chance >>>> to comment. >>>> >>>> Requested binding is Patch on the basis that no real interfaces are >>>> changing, >>>> although realistically there is probaby little chance that we'll >>>> backport this >>>> to S10. >>>> >>>> Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI >>>> This information is Copyright 2008 Sun Microsystems >>>> 1. Introduction >>>> 1.1. Project/Component Working Name: >>>> PCI Multimedia Class Interrupt Priorities >>>> 1.2. Name of Document Author/Supplier: >>>> Author: Garrett D'Amore >>>> 1.3 Date of This Document: >>>> 27 May, 2008 >>>> 4. Technical Description >>>> >>>> Fast-track: PCI Multimedia Class Interrupt Priorities >>>> Requested Binding: Patch >>>> >>>> Problem >>>> ------- >>>> >>>> The current Solaris PCI nexus logic assigns high level interrupts >>>> (level 12) >>>> to devices that are in PCI class 4 (multimedia class). This >>>> includes all >>>> audio devices. (Most of which are either subclass 1 for legacy audio >>>> devices, or 3 for newer hdaudio compliant devices.) >>>> >>>> However, none of the current Solaris device drivers can operate >>>> with such >>>> high interrupt priorities. All of the audio drivers in Solaris >>>> wind up >>>> reassigning an interrupt priority of 9 using the undocumented property >>>> "interrupt-priorities" in their driver.conf(4) to overcome this >>>> problem. >>>> >>>> (Recall that priority 10 is "lock level", the level above which >>>> device drivers >>>> must not use locks or other constructs which could result in >>>> putting a thread >>>> to sleep.) >>>> >>>> The project team is unaware of device drivers for any hardware in the >>>> multimedia class *other* than audio devices. >>>> >>>> The new audio framework proposed in PSARC 2008/318 will also be >>>> unable to >>>> function with high-level interrupts. >>>> >>>> Solution >>>> -------- >>>> >>>> We propose to change the default interrupt-priority for all devices >>>> in the >>>> multimedia class (PCI class 4) to 9. Experience has shown that this >>>> level is sufficiently high to meet the needs of low-latency audio >>>> devices, >>>> without requiring extraordinary measures normally required when >>>> dealing with >>>> high-level interrupts. >>>> >>>> As indicated, we are unaware of any devices supported by Solaris >>>> that are in >>>> the multimedia class other than those associated with audio support. >>>> >>>> 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 >>>> >>>> >> --Boundary_(ID_zWT9L/3Rda+WMOqNnj61zw)-- From Wesley.Shao@sun.com Wed May 28 13:24:17 2008 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 m4SKOG3b019985 for ; Wed, 28 May 2008 13:24:16 -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 m4SKOGHn014956 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 28 May 2008 13:24:16 -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 <0K1L00M01I0GD800@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 28 May 2008 14:24:16 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1L00522I0FCYC0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 28 May 2008 14:24:16 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m4SKOFHm008191 for ; Wed, 28 May 2008 13:24:15 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K1L00A01HSCZM00@fe-sfbay-09.sun.com> (original mail from Wesley.Shao@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 28 May 2008 13:24:15 -0700 (PDT) Received: from [129.146.96.108] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K1L00H27I0EHWD0@fe-sfbay-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 28 May 2008 13:24:14 -0700 (PDT) Date: Wed, 28 May 2008 13:26:34 -0700 From: Wesley Shao Subject: Re: [Fwd: Re: PCI Multimedia Class Interrupt Priorities [PSARC/2008/343 FastTrack timeout 06/03/2008]] In-reply-to: <483DBAEB.3000400@sun.com> Sender: Wesley.Shao@sun.com To: "Garrett D'Amore" Cc: PSARC-ext Message-id: <483DBFFA.9080403@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <483DBAEB.3000400@sun.com> User-Agent: Thunderbird 2.0.0.12 (X11/20080422) Status: RO Content-Length: 6397 Today, 7 or 8 doesn't make much difference since practically no one is using 7 or 8. Some bus controllers are defaulted to use 9 because they could be proxy-ing interrupts on other devices behalf, but that is just the original intent and isn't known for sure. Going forward, for DMA devices, we need to push them as low as they can. As long as audio is above 6, we shouldn't be breaking any relative priority (thus causing performance differentiations, or video goes out of sync with audio). On a side note, we should move the rest of the 9 crowd (bridges, etc) to 8 and leave 9 for error handling. Currently error handling is above lock level and we are having major issues with it. That would be a different case though. In short, I think 7 is a better fit for audio. Wes Garrett D'Amore wrote: > Resending, since I forgot to add the CC to PSARC! Doh! > > ------------------------------------------------------------------------ > > Subject: > Re: PCI Multimedia Class Interrupt Priorities [PSARC/2008/343 > FastTrack timeout 06/03/2008] > From: > Garrett D'Amore > Date: > Wed, 28 May 2008 13:04:06 -0700 > To: > Wesley Shao > > To: > Wesley Shao > > > Wesley Shao wrote: >> I can't think of reasons for below audio and above networking. Modern >> audio devices (especially the HD ones) are all DMA based, interrupt >> priority becomes relatively less important. I would like to push for 7 >> if we can. > Why? (I can't think of reasons either, but then again I can't think of > reasons for between audio and lock level.) > > Put another way, I'm not sure we buy anything by further reducing the > level below 8. > > I can definitely think of good reasons why even with DMA, interrupts > needs to be serviced in a timely fashion. (Synchronization of audio > with video, games, etc. as one example. Certain kinds of low latency > applications such as echo cancellation, and VoIP processing, are other > examples where one wants to make sure that the processing latency is > as low as we can easily make it.) > > Btw, I'm putting PSARC back on the distribution list for this, as this > discussion really needs to be recorded in the case log. > > At ARC today, this case was approved for level 8. Its probably a > minor update if we think we should move to level 7, but I am a bit > more hesitant there, given the need for audio drivers to get serviced > promptly. > > -- Garrett >> >> Wes >> >> Garrett D'Amore wrote: >>> Wesley Shao wrote: >>>> Why not making it even lower, like 7 or 8? There are virtually no >>>> drivers >>>> using 7 or higher. That will give some breathing room in case we >>>> have to >>>> debug some drivers and want to put them between audio and 10. >>> >>> I'm open to this idea. Level 9 was what was already in use, and >>> seemed to be well tested, which is why I proposed it. But I'd be >>> happy to use 8, as well. I don't think audio drivers have any >>> dependencies on any other drivers/devices, apart from typical >>> lock-oriented dependencies upon the system timer. >>> >>> Using 8 allows 7 to be used for things that are "just below" audio, >>> and 9 to be used for things that are "just above". (I can't think >>> of any examples of either one of those... but maybe someday someone >>> else will.) >>> >>> Does anyone else have any thoughts? >>> >>> -- Garrett >>>> >>>> Wes >>>> >>>> Garrett D'Amore - sun microsystems wrote: >>>>> I'm submitting this fast-track case on my own behalf. It probably >>>>> could >>>>> qualify for self-review, but I want to give any interested parties >>>>> a chance >>>>> to comment. >>>>> >>>>> Requested binding is Patch on the basis that no real interfaces >>>>> are changing, >>>>> although realistically there is probaby little chance that we'll >>>>> backport this >>>>> to S10. >>>>> >>>>> Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI >>>>> This information is Copyright 2008 Sun Microsystems >>>>> 1. Introduction >>>>> 1.1. Project/Component Working Name: >>>>> PCI Multimedia Class Interrupt Priorities >>>>> 1.2. Name of Document Author/Supplier: >>>>> Author: Garrett D'Amore >>>>> 1.3 Date of This Document: >>>>> 27 May, 2008 >>>>> 4. Technical Description >>>>> >>>>> Fast-track: PCI Multimedia Class Interrupt Priorities >>>>> Requested Binding: Patch >>>>> >>>>> Problem >>>>> ------- >>>>> >>>>> The current Solaris PCI nexus logic assigns high level interrupts >>>>> (level 12) >>>>> to devices that are in PCI class 4 (multimedia class). This >>>>> includes all >>>>> audio devices. (Most of which are either subclass 1 for legacy audio >>>>> devices, or 3 for newer hdaudio compliant devices.) >>>>> >>>>> However, none of the current Solaris device drivers can operate >>>>> with such >>>>> high interrupt priorities. All of the audio drivers in Solaris >>>>> wind up >>>>> reassigning an interrupt priority of 9 using the undocumented >>>>> property >>>>> "interrupt-priorities" in their driver.conf(4) to overcome this >>>>> problem. >>>>> >>>>> (Recall that priority 10 is "lock level", the level above which >>>>> device drivers >>>>> must not use locks or other constructs which could result in >>>>> putting a thread >>>>> to sleep.) >>>>> >>>>> The project team is unaware of device drivers for any hardware in the >>>>> multimedia class *other* than audio devices. >>>>> >>>>> The new audio framework proposed in PSARC 2008/318 will also be >>>>> unable to >>>>> function with high-level interrupts. >>>>> >>>>> Solution >>>>> -------- >>>>> >>>>> We propose to change the default interrupt-priority for all >>>>> devices in the >>>>> multimedia class (PCI class 4) to 9. Experience has shown that this >>>>> level is sufficiently high to meet the needs of low-latency audio >>>>> devices, >>>>> without requiring extraordinary measures normally required when >>>>> dealing with >>>>> high-level interrupts. >>>>> >>>>> As indicated, we are unaware of any devices supported by Solaris >>>>> that are in >>>>> the multimedia class other than those associated with audio support. >>>>> >>>>> 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 gdamore@sun.com Wed May 28 13:29:55 2008 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 m4SKTti7020343 for ; Wed, 28 May 2008 13:29:55 -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 m4SKTqc6016520 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 28 May 2008 13:29:54 -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 <0K1L00M0BI9TRQ00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 May 2008 14:29:53 -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 <0K1L005JHI9SD0C0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 May 2008 14:29:52 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m4SKTq1I014441 for ; Wed, 28 May 2008 13:29:52 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K1L00J01I2RPQ00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 May 2008 13:29:52 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K1L00HLEI9NHWF0@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 May 2008 13:29:47 -0700 (PDT) Date: Wed, 28 May 2008 13:22:40 -0700 From: "Garrett D'Amore" Subject: Re: [Fwd: Re: PCI Multimedia Class Interrupt Priorities [PSARC/2008/343 FastTrack timeout 06/03/2008]] In-reply-to: <483DBFFA.9080403@sun.com> Sender: Garrett.Damore@sun.com To: Wesley Shao Cc: PSARC-ext Message-id: <483DBF10.3030707@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <483DBAEB.3000400@sun.com> <483DBFFA.9080403@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 7394 Okay, it sounds like what you're requesting is really a change of additional things, outside the scope of this case. Can I suggest we go forward with 8 for now, and if you're going to do some additional changes to error handling, bridges, or other things, you run another case to make those changes? (And you can push audio down to 7 at that time, if you need to.) Also, not *all* audio devices are DMA. There are several audio devices which are PIO driven. The nice thing about this case is, once its done, we can remove the interrupt-priorities override property from the driver.conf files, so that if you want to adjust the priorities later, you can do so in the nexus code, and not have to touch a gazillion different .conf files. -- Garrett Wesley Shao wrote: > Today, 7 or 8 doesn't make much difference since practically no one is > using 7 or 8. Some bus controllers are defaulted to use 9 because they > could be proxy-ing interrupts on other devices behalf, but that is > just the original intent and isn't known for sure. > > Going forward, for DMA devices, we need to push them as low as they can. > As long as audio is above 6, we shouldn't be breaking any relative > priority (thus causing performance differentiations, or video goes out > of sync with audio). > > On a side note, we should move the rest of the 9 crowd (bridges, etc) to > 8 and leave 9 for error handling. Currently error handling is above lock > level and we are having major issues with it. That would be a different > case though. > > In short, I think 7 is a better fit for audio. > > Wes > > Garrett D'Amore wrote: >> Resending, since I forgot to add the CC to PSARC! Doh! >> >> ------------------------------------------------------------------------ >> >> Subject: >> Re: PCI Multimedia Class Interrupt Priorities [PSARC/2008/343 >> FastTrack timeout 06/03/2008] >> From: >> Garrett D'Amore >> Date: >> Wed, 28 May 2008 13:04:06 -0700 >> To: >> Wesley Shao >> >> To: >> Wesley Shao >> >> >> Wesley Shao wrote: >>> I can't think of reasons for below audio and above networking. Modern >>> audio devices (especially the HD ones) are all DMA based, interrupt >>> priority becomes relatively less important. I would like to push for 7 >>> if we can. >> Why? (I can't think of reasons either, but then again I can't think >> of reasons for between audio and lock level.) >> >> Put another way, I'm not sure we buy anything by further reducing the >> level below 8. >> >> I can definitely think of good reasons why even with DMA, interrupts >> needs to be serviced in a timely fashion. (Synchronization of audio >> with video, games, etc. as one example. Certain kinds of low latency >> applications such as echo cancellation, and VoIP processing, are >> other examples where one wants to make sure that the processing >> latency is as low as we can easily make it.) >> >> Btw, I'm putting PSARC back on the distribution list for this, as >> this discussion really needs to be recorded in the case log. >> >> At ARC today, this case was approved for level 8. Its probably a >> minor update if we think we should move to level 7, but I am a bit >> more hesitant there, given the need for audio drivers to get serviced >> promptly. >> >> -- Garrett >>> >>> Wes >>> >>> Garrett D'Amore wrote: >>>> Wesley Shao wrote: >>>>> Why not making it even lower, like 7 or 8? There are virtually no >>>>> drivers >>>>> using 7 or higher. That will give some breathing room in case we >>>>> have to >>>>> debug some drivers and want to put them between audio and 10. >>>> >>>> I'm open to this idea. Level 9 was what was already in use, and >>>> seemed to be well tested, which is why I proposed it. But I'd be >>>> happy to use 8, as well. I don't think audio drivers have any >>>> dependencies on any other drivers/devices, apart from typical >>>> lock-oriented dependencies upon the system timer. >>>> >>>> Using 8 allows 7 to be used for things that are "just below" audio, >>>> and 9 to be used for things that are "just above". (I can't think >>>> of any examples of either one of those... but maybe someday someone >>>> else will.) >>>> >>>> Does anyone else have any thoughts? >>>> >>>> -- Garrett >>>>> >>>>> Wes >>>>> >>>>> Garrett D'Amore - sun microsystems wrote: >>>>>> I'm submitting this fast-track case on my own behalf. It >>>>>> probably could >>>>>> qualify for self-review, but I want to give any interested >>>>>> parties a chance >>>>>> to comment. >>>>>> >>>>>> Requested binding is Patch on the basis that no real interfaces >>>>>> are changing, >>>>>> although realistically there is probaby little chance that we'll >>>>>> backport this >>>>>> to S10. >>>>>> >>>>>> Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI >>>>>> This information is Copyright 2008 Sun Microsystems >>>>>> 1. Introduction >>>>>> 1.1. Project/Component Working Name: >>>>>> PCI Multimedia Class Interrupt Priorities >>>>>> 1.2. Name of Document Author/Supplier: >>>>>> Author: Garrett D'Amore >>>>>> 1.3 Date of This Document: >>>>>> 27 May, 2008 >>>>>> 4. Technical Description >>>>>> >>>>>> Fast-track: PCI Multimedia Class Interrupt Priorities >>>>>> Requested Binding: Patch >>>>>> >>>>>> Problem >>>>>> ------- >>>>>> >>>>>> The current Solaris PCI nexus logic assigns high level interrupts >>>>>> (level 12) >>>>>> to devices that are in PCI class 4 (multimedia class). This >>>>>> includes all >>>>>> audio devices. (Most of which are either subclass 1 for legacy >>>>>> audio >>>>>> devices, or 3 for newer hdaudio compliant devices.) >>>>>> >>>>>> However, none of the current Solaris device drivers can operate >>>>>> with such >>>>>> high interrupt priorities. All of the audio drivers in Solaris >>>>>> wind up >>>>>> reassigning an interrupt priority of 9 using the undocumented >>>>>> property >>>>>> "interrupt-priorities" in their driver.conf(4) to overcome this >>>>>> problem. >>>>>> >>>>>> (Recall that priority 10 is "lock level", the level above which >>>>>> device drivers >>>>>> must not use locks or other constructs which could result in >>>>>> putting a thread >>>>>> to sleep.) >>>>>> >>>>>> The project team is unaware of device drivers for any hardware in >>>>>> the >>>>>> multimedia class *other* than audio devices. >>>>>> >>>>>> The new audio framework proposed in PSARC 2008/318 will also be >>>>>> unable to >>>>>> function with high-level interrupts. >>>>>> >>>>>> Solution >>>>>> -------- >>>>>> >>>>>> We propose to change the default interrupt-priority for all >>>>>> devices in the >>>>>> multimedia class (PCI class 4) to 9. Experience has shown that this >>>>>> level is sufficiently high to meet the needs of low-latency audio >>>>>> devices, >>>>>> without requiring extraordinary measures normally required when >>>>>> dealing with >>>>>> high-level interrupts. >>>>>> >>>>>> As indicated, we are unaware of any devices supported by Solaris >>>>>> that are in >>>>>> the multimedia class other than those associated with audio support. >>>>>> >>>>>> 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 Wesley.Shao@sun.com Wed May 28 13:33:43 2008 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 m4SKXgKL020394 for ; Wed, 28 May 2008 13:33:43 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m4SKXdYm024871 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 28 May 2008 21:33:41 +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 <0K1L00F03IG3Q300@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 May 2008 13:33:39 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1L00E8QIG2DC20@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 May 2008 13:33:38 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m4SKXcHL009424 for ; Wed, 28 May 2008 13:33:38 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K1L00J01I2RPQ00@fe-sfbay-09.sun.com> (original mail from Wesley.Shao@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 May 2008 13:33:38 -0700 (PDT) Received: from [129.146.96.108] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K1L007LVIG2W300@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 May 2008 13:33:38 -0700 (PDT) Date: Wed, 28 May 2008 13:35:58 -0700 From: Wesley Shao Subject: Re: PCI Multimedia Class Interrupt Priorities [PSARC/2008/343 FastTrack timeout 06/03/2008] In-reply-to: <483DBF10.3030707@sun.com> Sender: Wesley.Shao@sun.com To: "Garrett D'Amore" Cc: PSARC-ext Message-id: <483DC22E.5080900@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <483DBAEB.3000400@sun.com> <483DBFFA.9080403@sun.com> <483DBF10.3030707@sun.com> User-Agent: Thunderbird 2.0.0.12 (X11/20080422) Status: RO Content-Length: 7699 I have no objection to that. Thanks, Wes Garrett D'Amore wrote: > Okay, it sounds like what you're requesting is really a change of > additional things, outside the scope of this case. > > Can I suggest we go forward with 8 for now, and if you're going to do > some additional changes to error handling, bridges, or other things, > you run another case to make those changes? (And you can push audio > down to 7 at that time, if you need to.) > > Also, not *all* audio devices are DMA. There are several audio > devices which are PIO driven. > > The nice thing about this case is, once its done, we can remove the > interrupt-priorities override property from the driver.conf files, so > that if you want to adjust the priorities later, you can do so in the > nexus code, and not have to touch a gazillion different .conf files. > > -- Garrett > > Wesley Shao wrote: >> Today, 7 or 8 doesn't make much difference since practically no one is >> using 7 or 8. Some bus controllers are defaulted to use 9 because they >> could be proxy-ing interrupts on other devices behalf, but that is >> just the original intent and isn't known for sure. >> >> Going forward, for DMA devices, we need to push them as low as they can. >> As long as audio is above 6, we shouldn't be breaking any relative >> priority (thus causing performance differentiations, or video goes out >> of sync with audio). >> >> On a side note, we should move the rest of the 9 crowd (bridges, etc) to >> 8 and leave 9 for error handling. Currently error handling is above lock >> level and we are having major issues with it. That would be a different >> case though. >> >> In short, I think 7 is a better fit for audio. >> >> Wes >> >> Garrett D'Amore wrote: >>> Resending, since I forgot to add the CC to PSARC! Doh! >>> >>> ------------------------------------------------------------------------ >>> >>> >>> Subject: >>> Re: PCI Multimedia Class Interrupt Priorities [PSARC/2008/343 >>> FastTrack timeout 06/03/2008] >>> From: >>> Garrett D'Amore >>> Date: >>> Wed, 28 May 2008 13:04:06 -0700 >>> To: >>> Wesley Shao >>> >>> To: >>> Wesley Shao >>> >>> >>> Wesley Shao wrote: >>>> I can't think of reasons for below audio and above networking. Modern >>>> audio devices (especially the HD ones) are all DMA based, interrupt >>>> priority becomes relatively less important. I would like to push for 7 >>>> if we can. >>> Why? (I can't think of reasons either, but then again I can't think >>> of reasons for between audio and lock level.) >>> >>> Put another way, I'm not sure we buy anything by further reducing >>> the level below 8. >>> >>> I can definitely think of good reasons why even with DMA, interrupts >>> needs to be serviced in a timely fashion. (Synchronization of audio >>> with video, games, etc. as one example. Certain kinds of low >>> latency applications such as echo cancellation, and VoIP processing, >>> are other examples where one wants to make sure that the processing >>> latency is as low as we can easily make it.) >>> >>> Btw, I'm putting PSARC back on the distribution list for this, as >>> this discussion really needs to be recorded in the case log. >>> >>> At ARC today, this case was approved for level 8. Its probably a >>> minor update if we think we should move to level 7, but I am a bit >>> more hesitant there, given the need for audio drivers to get >>> serviced promptly. >>> >>> -- Garrett >>>> >>>> Wes >>>> >>>> Garrett D'Amore wrote: >>>>> Wesley Shao wrote: >>>>>> Why not making it even lower, like 7 or 8? There are virtually no >>>>>> drivers >>>>>> using 7 or higher. That will give some breathing room in case we >>>>>> have to >>>>>> debug some drivers and want to put them between audio and 10. >>>>> >>>>> I'm open to this idea. Level 9 was what was already in use, and >>>>> seemed to be well tested, which is why I proposed it. But I'd be >>>>> happy to use 8, as well. I don't think audio drivers have any >>>>> dependencies on any other drivers/devices, apart from typical >>>>> lock-oriented dependencies upon the system timer. >>>>> >>>>> Using 8 allows 7 to be used for things that are "just below" >>>>> audio, and 9 to be used for things that are "just above". (I >>>>> can't think of any examples of either one of those... but maybe >>>>> someday someone else will.) >>>>> >>>>> Does anyone else have any thoughts? >>>>> >>>>> -- Garrett >>>>>> >>>>>> Wes >>>>>> >>>>>> Garrett D'Amore - sun microsystems wrote: >>>>>>> I'm submitting this fast-track case on my own behalf. It >>>>>>> probably could >>>>>>> qualify for self-review, but I want to give any interested >>>>>>> parties a chance >>>>>>> to comment. >>>>>>> >>>>>>> Requested binding is Patch on the basis that no real interfaces >>>>>>> are changing, >>>>>>> although realistically there is probaby little chance that we'll >>>>>>> backport this >>>>>>> to S10. >>>>>>> >>>>>>> Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI >>>>>>> This information is Copyright 2008 Sun Microsystems >>>>>>> 1. Introduction >>>>>>> 1.1. Project/Component Working Name: >>>>>>> PCI Multimedia Class Interrupt Priorities >>>>>>> 1.2. Name of Document Author/Supplier: >>>>>>> Author: Garrett D'Amore >>>>>>> 1.3 Date of This Document: >>>>>>> 27 May, 2008 >>>>>>> 4. Technical Description >>>>>>> >>>>>>> Fast-track: PCI Multimedia Class Interrupt Priorities >>>>>>> Requested Binding: Patch >>>>>>> >>>>>>> Problem >>>>>>> ------- >>>>>>> >>>>>>> The current Solaris PCI nexus logic assigns high level >>>>>>> interrupts (level 12) >>>>>>> to devices that are in PCI class 4 (multimedia class). This >>>>>>> includes all >>>>>>> audio devices. (Most of which are either subclass 1 for legacy >>>>>>> audio >>>>>>> devices, or 3 for newer hdaudio compliant devices.) >>>>>>> >>>>>>> However, none of the current Solaris device drivers can operate >>>>>>> with such >>>>>>> high interrupt priorities. All of the audio drivers in Solaris >>>>>>> wind up >>>>>>> reassigning an interrupt priority of 9 using the undocumented >>>>>>> property >>>>>>> "interrupt-priorities" in their driver.conf(4) to overcome this >>>>>>> problem. >>>>>>> >>>>>>> (Recall that priority 10 is "lock level", the level above which >>>>>>> device drivers >>>>>>> must not use locks or other constructs which could result in >>>>>>> putting a thread >>>>>>> to sleep.) >>>>>>> >>>>>>> The project team is unaware of device drivers for any hardware >>>>>>> in the >>>>>>> multimedia class *other* than audio devices. >>>>>>> >>>>>>> The new audio framework proposed in PSARC 2008/318 will also be >>>>>>> unable to >>>>>>> function with high-level interrupts. >>>>>>> >>>>>>> Solution >>>>>>> -------- >>>>>>> >>>>>>> We propose to change the default interrupt-priority for all >>>>>>> devices in the >>>>>>> multimedia class (PCI class 4) to 9. Experience has shown that >>>>>>> this >>>>>>> level is sufficiently high to meet the needs of low-latency >>>>>>> audio devices, >>>>>>> without requiring extraordinary measures normally required when >>>>>>> dealing with >>>>>>> high-level interrupts. >>>>>>> >>>>>>> As indicated, we are unaware of any devices supported by Solaris >>>>>>> that are in >>>>>>> the multimedia class other than those associated with audio >>>>>>> support. >>>>>>> >>>>>>> 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 gdamore@sun.com Wed May 28 13:37:40 2008 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 m4SKbenr020450 for ; Wed, 28 May 2008 13:37:40 -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 m4SKbe1O018650 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 28 May 2008 13:37:40 -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 <0K1L00F07IMQWK00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 May 2008 13:37:38 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1L00ELBIMOD830@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 May 2008 13:37:36 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m4SKbacV009995 for ; Wed, 28 May 2008 13:37:36 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K1L00301FIKM000@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 May 2008 13:37:36 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K1L007ELIMDW320@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 May 2008 13:37:25 -0700 (PDT) Date: Wed, 28 May 2008 13:30:18 -0700 From: "Garrett D'Amore" Subject: Re: PCI Multimedia Class Interrupt Priorities [PSARC/2008/343 FastTrack timeout 06/03/2008] In-reply-to: <483DC22E.5080900@sun.com> Sender: Garrett.Damore@sun.com To: Wesley Shao Cc: PSARC-ext Message-id: <483DC0DA.90004@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <483DBAEB.3000400@sun.com> <483DBFFA.9080403@sun.com> <483DBF10.3030707@sun.com> <483DC22E.5080900@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 8026 OK. Thanks. I'm marking this case approved. - Garrett Wesley Shao wrote: > I have no objection to that. > > Thanks, > > Wes > > Garrett D'Amore wrote: >> Okay, it sounds like what you're requesting is really a change of >> additional things, outside the scope of this case. >> >> Can I suggest we go forward with 8 for now, and if you're going to do >> some additional changes to error handling, bridges, or other things, >> you run another case to make those changes? (And you can push audio >> down to 7 at that time, if you need to.) >> >> Also, not *all* audio devices are DMA. There are several audio >> devices which are PIO driven. >> >> The nice thing about this case is, once its done, we can remove the >> interrupt-priorities override property from the driver.conf files, so >> that if you want to adjust the priorities later, you can do so in the >> nexus code, and not have to touch a gazillion different .conf files. >> >> -- Garrett >> >> Wesley Shao wrote: >>> Today, 7 or 8 doesn't make much difference since practically no one is >>> using 7 or 8. Some bus controllers are defaulted to use 9 because they >>> could be proxy-ing interrupts on other devices behalf, but that is >>> just the original intent and isn't known for sure. >>> >>> Going forward, for DMA devices, we need to push them as low as they >>> can. >>> As long as audio is above 6, we shouldn't be breaking any relative >>> priority (thus causing performance differentiations, or video goes out >>> of sync with audio). >>> >>> On a side note, we should move the rest of the 9 crowd (bridges, >>> etc) to >>> 8 and leave 9 for error handling. Currently error handling is above >>> lock >>> level and we are having major issues with it. That would be a different >>> case though. >>> >>> In short, I think 7 is a better fit for audio. >>> >>> Wes >>> >>> Garrett D'Amore wrote: >>>> Resending, since I forgot to add the CC to PSARC! Doh! >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> Subject: >>>> Re: PCI Multimedia Class Interrupt Priorities [PSARC/2008/343 >>>> FastTrack timeout 06/03/2008] >>>> From: >>>> Garrett D'Amore >>>> Date: >>>> Wed, 28 May 2008 13:04:06 -0700 >>>> To: >>>> Wesley Shao >>>> >>>> To: >>>> Wesley Shao >>>> >>>> >>>> Wesley Shao wrote: >>>>> I can't think of reasons for below audio and above networking. Modern >>>>> audio devices (especially the HD ones) are all DMA based, interrupt >>>>> priority becomes relatively less important. I would like to push >>>>> for 7 >>>>> if we can. >>>> Why? (I can't think of reasons either, but then again I can't think >>>> of reasons for between audio and lock level.) >>>> >>>> Put another way, I'm not sure we buy anything by further reducing >>>> the level below 8. >>>> >>>> I can definitely think of good reasons why even with DMA, >>>> interrupts needs to be serviced in a timely fashion. >>>> (Synchronization of audio with video, games, etc. as one example. >>>> Certain kinds of low latency applications such as echo >>>> cancellation, and VoIP processing, are other examples where one >>>> wants to make sure that the processing latency is as low as we can >>>> easily make it.) >>>> >>>> Btw, I'm putting PSARC back on the distribution list for this, as >>>> this discussion really needs to be recorded in the case log. >>>> >>>> At ARC today, this case was approved for level 8. Its probably a >>>> minor update if we think we should move to level 7, but I am a bit >>>> more hesitant there, given the need for audio drivers to get >>>> serviced promptly. >>>> >>>> -- Garrett >>>>> >>>>> Wes >>>>> >>>>> Garrett D'Amore wrote: >>>>>> Wesley Shao wrote: >>>>>>> Why not making it even lower, like 7 or 8? There are virtually >>>>>>> no drivers >>>>>>> using 7 or higher. That will give some breathing room in case we >>>>>>> have to >>>>>>> debug some drivers and want to put them between audio and 10. >>>>>> >>>>>> I'm open to this idea. Level 9 was what was already in use, and >>>>>> seemed to be well tested, which is why I proposed it. But I'd be >>>>>> happy to use 8, as well. I don't think audio drivers have any >>>>>> dependencies on any other drivers/devices, apart from typical >>>>>> lock-oriented dependencies upon the system timer. >>>>>> >>>>>> Using 8 allows 7 to be used for things that are "just below" >>>>>> audio, and 9 to be used for things that are "just above". (I >>>>>> can't think of any examples of either one of those... but maybe >>>>>> someday someone else will.) >>>>>> >>>>>> Does anyone else have any thoughts? >>>>>> >>>>>> -- Garrett >>>>>>> >>>>>>> Wes >>>>>>> >>>>>>> Garrett D'Amore - sun microsystems wrote: >>>>>>>> I'm submitting this fast-track case on my own behalf. It >>>>>>>> probably could >>>>>>>> qualify for self-review, but I want to give any interested >>>>>>>> parties a chance >>>>>>>> to comment. >>>>>>>> >>>>>>>> Requested binding is Patch on the basis that no real interfaces >>>>>>>> are changing, >>>>>>>> although realistically there is probaby little chance that >>>>>>>> we'll backport this >>>>>>>> to S10. >>>>>>>> >>>>>>>> Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI >>>>>>>> This information is Copyright 2008 Sun Microsystems >>>>>>>> 1. Introduction >>>>>>>> 1.1. Project/Component Working Name: >>>>>>>> PCI Multimedia Class Interrupt Priorities >>>>>>>> 1.2. Name of Document Author/Supplier: >>>>>>>> Author: Garrett D'Amore >>>>>>>> 1.3 Date of This Document: >>>>>>>> 27 May, 2008 >>>>>>>> 4. Technical Description >>>>>>>> >>>>>>>> Fast-track: PCI Multimedia Class Interrupt Priorities >>>>>>>> Requested Binding: Patch >>>>>>>> >>>>>>>> Problem >>>>>>>> ------- >>>>>>>> >>>>>>>> The current Solaris PCI nexus logic assigns high level >>>>>>>> interrupts (level 12) >>>>>>>> to devices that are in PCI class 4 (multimedia class). This >>>>>>>> includes all >>>>>>>> audio devices. (Most of which are either subclass 1 for legacy >>>>>>>> audio >>>>>>>> devices, or 3 for newer hdaudio compliant devices.) >>>>>>>> >>>>>>>> However, none of the current Solaris device drivers can operate >>>>>>>> with such >>>>>>>> high interrupt priorities. All of the audio drivers in Solaris >>>>>>>> wind up >>>>>>>> reassigning an interrupt priority of 9 using the undocumented >>>>>>>> property >>>>>>>> "interrupt-priorities" in their driver.conf(4) to overcome this >>>>>>>> problem. >>>>>>>> >>>>>>>> (Recall that priority 10 is "lock level", the level above which >>>>>>>> device drivers >>>>>>>> must not use locks or other constructs which could result in >>>>>>>> putting a thread >>>>>>>> to sleep.) >>>>>>>> >>>>>>>> The project team is unaware of device drivers for any hardware >>>>>>>> in the >>>>>>>> multimedia class *other* than audio devices. >>>>>>>> >>>>>>>> The new audio framework proposed in PSARC 2008/318 will also be >>>>>>>> unable to >>>>>>>> function with high-level interrupts. >>>>>>>> >>>>>>>> Solution >>>>>>>> -------- >>>>>>>> >>>>>>>> We propose to change the default interrupt-priority for all >>>>>>>> devices in the >>>>>>>> multimedia class (PCI class 4) to 9. Experience has shown that >>>>>>>> this >>>>>>>> level is sufficiently high to meet the needs of low-latency >>>>>>>> audio devices, >>>>>>>> without requiring extraordinary measures normally required when >>>>>>>> dealing with >>>>>>>> high-level interrupts. >>>>>>>> >>>>>>>> As indicated, we are unaware of any devices supported by >>>>>>>> Solaris that are in >>>>>>>> the multimedia class other than those associated with audio >>>>>>>> support. >>>>>>>> >>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>> >>>> >>>> >>> >>