[PATCH 0/8] Suspend block api (version 8)
in [Kernel]
|
Prev: [ANN] Linux Security Summit 2010 - Announcement and CFP
Next: [PATCH 4/8] PM: suspend_block: Add debugfs file
From: James Bottomley on 3 Jun 2010 11:00 On Thu, 2010-06-03 at 16:35 +0200, Thomas Gleixner wrote: > On Thu, 3 Jun 2010, James Bottomley wrote: > > > On Thu, 2010-06-03 at 11:03 +0100, Alan Cox wrote: > > > > [mtg: ] This has been a pain point for the PM_QOS implementation. They change the constrain back and forth at the transaction level of the i2c driver. The pm_qos code really wasn't made to deal with such hot path use, as each such change triggers a re-computation of what the aggregate qos request is. > > > > > > That should be trivial in the usual case because 99% of the time you can > > > hot path > > > > > > the QoS entry changing is the latest one > > > there have been no other changes > > > If it is valid I can use the cached previous aggregate I cunningly > > > saved in the top QoS entry when I computed the new one > > > > > > (ie most of the time from the kernel side you have a QoS stack) > > > > It's not just the list based computation: that's trivial to fix, as you > > say ... the other problem is the notifier chain, because that's blocking > > and could be long. Could we invoke the notifier through a workqueue? > > It doesn't seem to have veto power, so it's pure notification, does it > > matter if the notice is delayed (as long as it's in order)? > > It depends on the information type and for a lot of things we might > get away without notifiers. > > The only real issue is when you need to get other cores out of their > deep idle state to make a new constraint work. That's what we do with > the DMA latency notifier right now. But the only DMA latency notifier is cpuidle_latency_notifier. That looks callable from atomic context, so we could have two chains: one atomic and one not. The only other notifier in use is the ieee80211_max_network_latency, which uses mutexes, so does require user context. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Florian Mickler on 3 Jun 2010 11:20 On Thu, 03 Jun 2010 09:36:34 -0500 James Bottomley <James.Bottomley(a)suse.de> wrote: > On Thu, 2010-06-03 at 00:10 -0700, Arve Hj�nnev�g wrote: > > On Wed, Jun 2, 2010 at 10:40 PM, mark gross <640e9920(a)gmail.com> wrote: > > > On Wed, Jun 02, 2010 at 09:54:15PM -0700, Brian Swetland wrote: > > >> On Wed, Jun 2, 2010 at 8:18 PM, mark gross <640e9920(a)gmail.com> wrote: > > >> > On Wed, Jun 02, 2010 at 02:58:30PM -0700, Arve Hj�nnev�g wrote: > > >> >> > > >> >> The list is not short. You have all the inactive and active > > >> >> constraints on the same list. If you change it to a two level list > > >> >> though, the list of unique values (which is the list you have to walk) > > >> >> may be short enough for a tree to be overkill. > > >> > > > >> > what have you seen in practice from the wake-lock stats? > > >> > > > >> > I'm having a hard time seeing where you could get more than just a > > >> > handfull. However; one could go to a dual list (like the scheduler) and > > >> > move inactive nodes from an active to inactive list, or we could simply > > >> > remove them from the list uppon inactivity. which would would well > > >> > after I change the api to have the client allocate the memory for the > > >> > nodes... BUT, if your moving things in and out of a list a lot, I'm not > > >> > sure the break even point where changing the structure helps. > > >> > > > >> > We'll need to try it. > > >> > > > >> > I think we will almost never see more than 10 list elements. > > >> > > > >> > --mgross > > >> > > > >> > > > >> > > >> I see about 80 (based on the batteryinfo dump) on my Nexus One > > >> (QSD8250, Android Froyo): > > > > > > shucks. > > > > > > well I think for a pm_qos class that has boolean dynamic range we can > > > get away with not walking the list on every request update. we can use > > > a counter, and the list will be for mostly for stats. > > > > > > > Did you give any thought to my suggestion to only use one entry per > > unique value on the first level list and then use secondary lists of > > identical values. That way if you only have two constraints values the > > list you have to walk when updating a request will never have more > > than two entries regardless of how many total request you have. > > > > A request update then becomes something like this: > > if on primary list { > > unlink from primary list > > if secondary list is not empty > > get next secondary entry and add in same spot on primary list > > } > > unlink from secondary list > > find new spot on primary list > > if already there > > add to secondary list > > else > > add to primary list > > This is just reinventing hash bucketed lists. To get the benefits, all > we do is implement an N state constraint as backed by an N bucketed hash > list, which the kernel already has all the internal mechanics for. > > James > http://www.itl.nist.gov/div897/sqg/dads/HTML/priorityque.html So no reinvention. Just using a common scheme. Cheers, Flo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Peter Zijlstra on 3 Jun 2010 11:30 On Thu, 2010-06-03 at 16:12 +0200, Florian Mickler wrote: > On Thu, 03 Jun 2010 09:40:02 +0200 > Peter Zijlstra <peterz(a)infradead.org> wrote: > > > Same for firefox, you can teach it to not render animated gifs and run > > javascript for invisible tabs, and once the screen-saver kicks in, > > nothing is visible (and with X telling apps their window is visible or > > not it knows), so it should go idle all of its own. > > > > Fix the friggin apps, don't kludge with freezing. > > Of course programs should be as smart as possible. But that is an > orthogonal problem. > > Suppose firefox were fixed. It still needs to fetch my rss feeds every > minute, because I'm sad if it doesn't. It just can't be fixed at the > application level. Sure it can, why would it need to fetch RSS feeds when the screen is off and nobody could possible see the result? So you can stop the timer when you know the window isn't visible or alternatively when the screensaver is active, I think most desktops have notification of that as well. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: James Bottomley on 3 Jun 2010 11:40 On Thu, 2010-06-03 at 17:17 +0200, Florian Mickler wrote: > On Thu, 03 Jun 2010 09:36:34 -0500 > James Bottomley <James.Bottomley(a)suse.de> wrote: > > > On Thu, 2010-06-03 at 00:10 -0700, Arve Hjønnevåg wrote: > > > On Wed, Jun 2, 2010 at 10:40 PM, mark gross <640e9920(a)gmail.com> wrote: > > > > On Wed, Jun 02, 2010 at 09:54:15PM -0700, Brian Swetland wrote: > > > >> On Wed, Jun 2, 2010 at 8:18 PM, mark gross <640e9920(a)gmail.com> wrote: > > > >> > On Wed, Jun 02, 2010 at 02:58:30PM -0700, Arve Hjønnevåg wrote: > > > >> >> > > > >> >> The list is not short. You have all the inactive and active > > > >> >> constraints on the same list. If you change it to a two level list > > > >> >> though, the list of unique values (which is the list you have to walk) > > > >> >> may be short enough for a tree to be overkill. > > > >> > > > > >> > what have you seen in practice from the wake-lock stats? > > > >> > > > > >> > I'm having a hard time seeing where you could get more than just a > > > >> > handfull. However; one could go to a dual list (like the scheduler) and > > > >> > move inactive nodes from an active to inactive list, or we could simply > > > >> > remove them from the list uppon inactivity. which would would well > > > >> > after I change the api to have the client allocate the memory for the > > > >> > nodes... BUT, if your moving things in and out of a list a lot, I'm not > > > >> > sure the break even point where changing the structure helps. > > > >> > > > > >> > We'll need to try it. > > > >> > > > > >> > I think we will almost never see more than 10 list elements. > > > >> > > > > >> > --mgross > > > >> > > > > >> > > > > >> > > > >> I see about 80 (based on the batteryinfo dump) on my Nexus One > > > >> (QSD8250, Android Froyo): > > > > > > > > shucks. > > > > > > > > well I think for a pm_qos class that has boolean dynamic range we can > > > > get away with not walking the list on every request update. we can use > > > > a counter, and the list will be for mostly for stats. > > > > > > > > > > Did you give any thought to my suggestion to only use one entry per > > > unique value on the first level list and then use secondary lists of > > > identical values. That way if you only have two constraints values the > > > list you have to walk when updating a request will never have more > > > than two entries regardless of how many total request you have. > > > > > > A request update then becomes something like this: > > > if on primary list { > > > unlink from primary list > > > if secondary list is not empty > > > get next secondary entry and add in same spot on primary list > > > } > > > unlink from secondary list > > > find new spot on primary list > > > if already there > > > add to secondary list > > > else > > > add to primary list > > > > This is just reinventing hash bucketed lists. To get the benefits, all > > we do is implement an N state constraint as backed by an N bucketed hash > > list, which the kernel already has all the internal mechanics for. > > > > James > > > > http://www.itl.nist.gov/div897/sqg/dads/HTML/priorityque.html > > So no reinvention. Just using a common scheme. By reinvention I meant open coding a common pattern for which the kernel already has an API. (Whether we go with hash buckets or plists). James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Gross, Mark on 3 Jun 2010 11:50
>-----Original Message----- >From: Kevin Hilman [mailto:khilman(a)deeprootsystems.com] >Sent: Thursday, June 03, 2010 7:43 AM >To: Peter Zijlstra >Cc: Alan Cox; Gross, Mark; Florian Mickler; James Bottomley; Arve >Hj�nnev�g; Neil Brown; tytso(a)mit.edu; LKML; Thomas Gleixner; Linux OMAP >Mailing List; Linux PM; felipe.balbi(a)nokia.com >Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8) > >Peter Zijlstra <peterz(a)infradead.org> writes: > >> On Thu, 2010-06-03 at 11:03 +0100, Alan Cox wrote: >>> > [mtg: ] This has been a pain point for the PM_QOS implementation. >>> They change the constrain back and forth at the transaction level of >>> the i2c driver. The pm_qos code really wasn't made to deal with such >>> hot path use, as each such change triggers a re-computation of what >>> the aggregate qos request is. >>> >>> That should be trivial in the usual case because 99% of the time you can >>> hot path >>> >>> the QoS entry changing is the latest one >>> there have been no other changes >>> If it is valid I can use the cached previous aggregate I cunningly >>> saved in the top QoS entry when I computed the new one >>> >>> (ie most of the time from the kernel side you have a QoS stack) >> >> Why would the kernel change the QoS state of a task? Why not have two >> interacting QoS variables, one for the task, one for the subsystem in >> question, and the action depends on their relative value? > >Yes, having a QoS parameter per-subsystem (or even per-device) is very >important for SoCs that have independently controlled powerdomains. >If all devices/subsystems in a particular powerdomain have QoS >parameters that permit, the power state of that powerdomain can be >lowered independently from system-wide power state and power states of >other power domains. > This seems similar to that pm_qos generalization into bus drivers we where waving our hands at during the collab summit in April? We never did get into meaningful detail at that time. --mgross -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |