* [PATCH]make the e->rule.xxx shorter in kernel auditfilter.c
From: Zhenwen Xu @ 2009-03-12 14:16 UTC (permalink / raw)
To: viro; +Cc: linux-kernel, linux-mm, linux-audit
make the e->rule.xxx shorter in kernel/auditfilter.c
--
---------------------------------
Zhenwen Xu - Open and Free
Home Page: http://zhwen.org
My Studio: http://dim4.cn
^ permalink raw reply
* Re: git checkout -b origin/mybranch origin/mybranch
From: John Tapsell @ 2009-03-12 14:14 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Johannes Schindelin, Git List
In-Reply-To: <fabb9a1e0903120643r3cfefdfej560ff7edda2be6f5@mail.gmail.com>
2009/3/12 Sverre Rabbelier <srabbelier@gmail.com>:
> Heya,
>
> On Thu, Mar 12, 2009 at 14:18, John Tapsell <johnflux@gmail.com> wrote:
>> Is probably a mistake by the user. We should warn the user and point
>> them in the right direction.
>
> The point is that we _already_ warned the user (like Dscho pointed
> out), and that(as you pointed out), it didn't work :P.
Just doing:
git branch -b origin/master origin/master
gives no error or warning at all.
John
>
> --
> Cheers,
>
> Sverre Rabbelier
>
^ permalink raw reply
* [PATCH]make the e->rule.xxx shorter in kernel auditfilter.c
From: Zhenwen Xu @ 2009-03-12 14:16 UTC (permalink / raw)
To: viro; +Cc: linux-kernel, linux-mm, linux-audit
make the e->rule.xxx shorter in kernel/auditfilter.c
--
---------------------------------
Zhenwen Xu - Open and Free
Home Page: http://zhwen.org
My Studio: http://dim4.cn
>From 99692dc640b278f1cb1a15646ce42f22e89c0f77 Mon Sep 17 00:00:00 2001
From: Zhenwen Xu <Helight.Xu@gmail.com>
Date: Thu, 12 Mar 2009 22:04:59 +0800
Subject: [PATCH] make the e->rule.xxx shorter in kernel/auditfilter.c
Signed-off-by: Zhenwen Xu <Helight.Xu@gmail.com>
---
kernel/auditfilter.c | 16 ++++++++--------
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
index fbf24d1..a6fe71f 100644
--- a/kernel/auditfilter.c
+++ b/kernel/auditfilter.c
@@ -135,18 +135,18 @@ static void audit_remove_watch(struct audit_watch *watch)
static inline void audit_free_rule(struct audit_entry *e)
{
int i;
-
+ struct audit_krule *erule = &e->rule;
/* some rules don't have associated watches */
- if (e->rule.watch)
- audit_put_watch(e->rule.watch);
- if (e->rule.fields)
- for (i = 0; i < e->rule.field_count; i++) {
- struct audit_field *f = &e->rule.fields[i];
+ if (erule->watch)
+ audit_put_watch(erule->watch);
+ if (erule->fields)
+ for (i = 0; i < erule->field_count; i++) {
+ struct audit_field *f = &erule->fields[i];
kfree(f->lsm_str);
security_audit_rule_free(f->lsm_rule);
}
- kfree(e->rule.fields);
- kfree(e->rule.filterkey);
+ kfree(erule->fields);
+ kfree(erule->filterkey);
kfree(e);
}
--
1.5.6.5
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* Re: [PATCH,v2][1/2] sata-mv: enable HDD led blinking when NCQ is active for GenIIe
From: Mark Lord @ 2009-03-12 14:15 UTC (permalink / raw)
To: Frans Pop
Cc: linux-arm, linux-ide, Saeed Bishara, Nicolas Pitre,
Lennert Buytenhek
In-Reply-To: <49B918D1.7020407@rtr.ca>
Mark Lord wrote:
> Frans Pop wrote:
>> On Wednesday 11 March 2009, Mark Lord wrote:
> ..
>>> Can you test this there and confirm that it still works for you?
>>> Please try switching NCQ on/off etc.. just to make sure.
>>
>> The LED behavior is correct with NCQ enabled: slow blink.
>> But if I disable NCQ blink mode is not turned off, the led continues
>> the slow blinking. So it looks as if just calling
>> mv_soc_led_blink_disable in mv_edma_cfg is not sufficient.
> ..
>
> Exactly, *how*, did you "disable NCQ blink mode".
..
Or rather, exactly *how* did you "disable NCQ" ?
Thanks
^ permalink raw reply
* Re: LWN article: ext4 and data loss
From: Martin Steigerwald @ 2009-03-12 14:14 UTC (permalink / raw)
To: xfs
In-Reply-To: <49B9097C.1070003@sandeen.net>
Am Donnerstag 12 März 2009 schrieb Eric Sandeen:
> Michael Monnerie wrote:
> > http://lwn.net/SubscriberLink/322823/e6979f02e5a73feb/
> >
> > Very good, maybe similar patches for XFS would help?
> > IANA Coder, but could be a hint.
> >
> > mfg zmi
>
> ext4 is taking its hints from XFS in this regard, not the other way
> around. XFS dealt with this long ago.
Hmmm, I remember having had similar issues with XFS not to long ago, where
at least some KDE configuration were lost or truncated. It seems
applications will have to get rid of behavioral assumptions regation
filesystem and use safe writing via fsync and whatever else for
configuration and other important files.
I am thinking about a bug report for KDE at least.
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* Re: [RFC v2: Patch 1/3] net: hand off skb list to other cpu to submit to upper layer
From: Andi Kleen @ 2009-03-12 14:34 UTC (permalink / raw)
To: Zhang, Yanmin
Cc: Andi Kleen, netdev, LKML, herbert, jesse.brandeburg, shemminger,
David Miller
In-Reply-To: <1236845792.2567.484.camel@ymzhang>
On Thu, Mar 12, 2009 at 04:16:32PM +0800, Zhang, Yanmin wrote:
>
> > Seems very inconvenient to have to configure this by hand.
> A little, but not too much, especially when we consider there is interrupt binding.
Interrupt binding is something popular for benchmarks, but most users
don't (and shouldn't need to) care. Having it work well out of the box
without special configuration is very important.
>
> > How about
> > auto selecting one that shares the same LLC or somesuch?
> There are 2 kinds of LLC sharing here.
> 1) RX/TX share the LLC;
> 2) All RX share the LLC of some cpus and TX share the LLC of other cpus.
>
> Item 1) is important, but sometimes item 2) is also important when the sending speed is
> very high and huge data is on flight which flushes cpu cache quickly.
> It's hard to distinguish the 2 different scenarioes automatically.
Why is it hard if you know the CPUs?
> > and just use the hash function on the
> > NIC.
> Sorry. I can't understand what the hash function of NIC is. Perhaps NIC hardware has something
> like hash function to decide the RX queue number based on SRC/DST?
There's a Microsoft spec for a standard hash function that does this
on NICs and all the serious ones support it these days. The hash
is normally used to select a MSI-X target based on the input header.
I think if that works your manual target shouldn't be necessary.
> > The trick here would
> > be to try to avoid reordering inside streams as far as possible,
> It's not to solve reorder issue. The start point is 10G NIC is very fast. We need some cpu
Point was that any solution shouldn't add more reordering. But when a RSS
hash is used there is no reordering on stream basis.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: [PATCH,v2][1/2] sata-mv: enable HDD led blinking when NCQ is active for GenIIe
From: Mark Lord @ 2009-03-12 14:14 UTC (permalink / raw)
To: Frans Pop
Cc: linux-arm, linux-ide, Saeed Bishara, Nicolas Pitre,
Lennert Buytenhek
In-Reply-To: <200903121240.55194.elendil@planet.nl>
Frans Pop wrote:
> On Wednesday 11 March 2009, Mark Lord wrote:
..
>> Can you test this there and confirm that it still works for you?
>> Please try switching NCQ on/off etc.. just to make sure.
>
> The LED behavior is correct with NCQ enabled: slow blink.
> But if I disable NCQ blink mode is not turned off, the led continues the
> slow blinking. So it looks as if just calling mv_soc_led_blink_disable in
> mv_edma_cfg is not sufficient.
..
Exactly, *how*, did you "disable NCQ blink mode".
thanks
^ permalink raw reply
* Re: Thanks for TX power patch
From: Bob Copeland @ 2009-03-12 14:14 UTC (permalink / raw)
To: Tulio Magno Quites Machado Filho
Cc: Maxim Levitsky, Nick Kossifidis, ath5k-devel, linux-wireless
In-Reply-To: <d94c510d0903110115s620c7851g391fcf00e644a113@mail.gmail.com>
On Wed, Mar 11, 2009 at 4:15 AM, Tulio Magno Quites Machado Filho
<tuliom@gmail.com> wrote:
> On Wed, Mar 11, 2009 at 12:39 AM, Maxim Levitsky
> <maximlevitsky@gmail.com> wrote:
>> If I unload/reload the ath5k, it seems to work. but at next suspend =
to
>> disk, once =A0system hung, other time it showed many panic, in somet=
hing
>> related to page allocator (one even was in page_alloc_pages or so)
>
> I'm getting some Kernel oopses after unloading ath5k with Nick patche=
s.
> But I'm still debugging it to find where is the problem.
Ditto here.. looks like a bug in ath5k_eeprom_free_pcal_info(), which h=
as:
struct ath5k_pdgain_info *pd =3D &chinfo->pd_curves[pdg];
if (pd !=3D NULL) {
kfree(pd->pd_step);
kfree(pd->pd_pwr);
kfree(pd);
}
kfree(pd) looks wrong, because pd_curves is the kzalloc()ed part, not
the array elements themselves. But I tried removing that and freeing
the pd_curves array outside of the loop and got more slab debugging
poop. So, I punt for now.
Also, every alloc of pd_step, and pd_pwr can potentially leak earlier
allocated memory on ENOMEM.
--=20
Bob Copeland %% www.bobcopeland.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] fix/improve generic page table walker
From: Matt Mackall @ 2009-03-12 14:10 UTC (permalink / raw)
To: Martin Schwidefsky
Cc: linux-kernel, linux-mm, Gerald Schaefer, akpm, Hugh Dickins,
Nick Piggin
In-Reply-To: <20090312093335.6dd67251@skybase>
[Nick and Hugh, maybe you can shed some light on this for me]
On Thu, 2009-03-12 at 09:33 +0100, Martin Schwidefsky wrote:
> On Wed, 11 Mar 2009 12:24:23 -0500
> Matt Mackall <mpm@selenic.com> wrote:
>
> > On Wed, 2009-03-11 at 14:49 +0100, Martin Schwidefsky wrote:
> > > From: Martin Schwidefsky <schwidefsky@de.ibm.com>
> > >
> > > On s390 the /proc/pid/pagemap interface is currently broken. This is
> > > caused by the unconditional loop over all pgd/pud entries as specified
> > > by the address range passed to walk_page_range. The tricky bit here
> > > is that the pgd++ in the outer loop may only be done if the page table
> > > really has 4 levels. For the pud++ in the second loop the page table needs
> > > to have at least 3 levels. With the dynamic page tables on s390 we can have
> > > page tables with 2, 3 or 4 levels. Which means that the pgd and/or the
> > > pud pointer can get out-of-bounds causing all kinds of mayhem.
> >
> > Not sure why this should be a problem without delving into the S390
> > code. After all, x86 has 2, 3, or 4 levels as well (at compile time) in
> > a way that's transparent to the walker.
>
> Its hard to understand without looking at the s390 details. The main
> difference between x86 and s390 in that respect is that on s390 the
> number of page table levels is determined at runtime on a per process
> basis. A compat process uses 2 levels, a 64 bit process starts with 3
> levels and can "upgrade" to 4 levels if something gets mapped above
> 4TB. Which means that a *pgd can point to a region-second (2**53 bytes),
> a region-third (2**42 bytes) or a segment table (2**31 bytes), a *pud
> can point to a region-third or a segment table. The page table
> primitives know about this semantic, in particular pud_offset and
> pmd_offset check the type of the page table pointed to by *pgd and *pud
> and do nothing with the pointer if it is a lower level page table.
> The only operation I can not "patch" is the pgd++/pud++ operation.
So in short, sometimes a pgd_t isn't really a pgd_t at all. It's another
object with different semantics that generic code can trip over.
Can I get you to explain why this is necessary or even preferable to
doing it the generic way where pgd_t has a fixed software meaning
regardless of how many hardware levels are in play?
--
http://selenic.com : development and support for Mercurial and Linux
^ permalink raw reply
* Re: [PATCH 01/10] Documentation
From: Vivek Goyal @ 2009-03-12 14:09 UTC (permalink / raw)
To: Peter Zijlstra
Cc: nauman, dpshah, lizf, mikew, fchecconi, paolo.valente, jens.axboe,
ryov, fernando, s-uchida, taka, guijianfeng, arozansk, jmoyer,
oz-kernel, dhaval, balbir, linux-kernel, containers, akpm, menage
In-Reply-To: <1236853490.5090.140.camel@laptop>
On Thu, Mar 12, 2009 at 11:24:50AM +0100, Peter Zijlstra wrote:
> On Wed, 2009-03-11 at 21:56 -0400, Vivek Goyal wrote:
> > +Going back to old behavior
> > +==========================
> > +In new scheme of things essentially we are creating hierarchical fair
> > +queuing logic in elevator layer and changing IO schedulers to make use of
> > +that logic so that end IO schedulers start supporting hierarchical scheduling.
> > +
> > +Elevator layer continues to support the old interfaces. So even if fair queuing
> > +is enabled at elevator layer, one can have both new hierarchical scheduler as
> > +well as old non-hierarchical scheduler operating.
> > +
> > +Also noop, deadline and AS have option of enabling hierarchical scheduling.
> > +If it is selected, fair queuing is done in hierarchical manner. If hierarchical
> > +scheduling is disabled, noop, deadline and AS should retain their existing
> > +behavior.
> > +
> > +CFQ is the only exception where one can not disable fair queuing as it is
> > +needed for providing fairness among various threads even in non-hierarchical
> > +mode.
> > +
> > +Various user visible config options
> > +===================================
> > +CONFIG_IOSCHED_NOOP_HIER
> > + - Enables hierchical fair queuing in noop. Not selecting this option
> > + leads to old behavior of noop.
> > +
> > +CONFIG_IOSCHED_DEADLINE_HIER
> > + - Enables hierchical fair queuing in deadline. Not selecting this
> > + option leads to old behavior of deadline.
> > +
> > +CONFIG_IOSCHED_AS_HIER
> > + - Enables hierchical fair queuing in AS. Not selecting this option
> > + leads to old behavior of AS.
> > +
> > +CONFIG_IOSCHED_CFQ_HIER
> > + - Enables hierarchical fair queuing in CFQ. Not selecting this option
> > + still does fair queuing among various queus but it is flat and not
> > + hierarchical.
>
> One worry I have is that these are compile time switches. Is there any
> way you can get the old AS/DEADLINE back when these are enabled but
> you're not actively using cgroups?
Hi Peter,
In principle, if one is not using cgroups, there is only one io queue
in the root group and most likely we should achieve the same behavior
as old schedulers. Just that some extra code gets into execution at
runtime.
I have not got a chance yet to do some numbers but I think this path
can be optimized enough that at run time effectively we don't see any
significant performance penalty and behavior of schedulers is almost
same as old ones.
Thanks
Vivek
^ permalink raw reply
* Re: [PATCH] fix/improve generic page table walker
From: Matt Mackall @ 2009-03-12 14:10 UTC (permalink / raw)
To: Martin Schwidefsky
Cc: linux-kernel, linux-mm, Gerald Schaefer, akpm, Hugh Dickins,
Nick Piggin
In-Reply-To: <20090312093335.6dd67251@skybase>
[Nick and Hugh, maybe you can shed some light on this for me]
On Thu, 2009-03-12 at 09:33 +0100, Martin Schwidefsky wrote:
> On Wed, 11 Mar 2009 12:24:23 -0500
> Matt Mackall <mpm@selenic.com> wrote:
>
> > On Wed, 2009-03-11 at 14:49 +0100, Martin Schwidefsky wrote:
> > > From: Martin Schwidefsky <schwidefsky@de.ibm.com>
> > >
> > > On s390 the /proc/pid/pagemap interface is currently broken. This is
> > > caused by the unconditional loop over all pgd/pud entries as specified
> > > by the address range passed to walk_page_range. The tricky bit here
> > > is that the pgd++ in the outer loop may only be done if the page table
> > > really has 4 levels. For the pud++ in the second loop the page table needs
> > > to have at least 3 levels. With the dynamic page tables on s390 we can have
> > > page tables with 2, 3 or 4 levels. Which means that the pgd and/or the
> > > pud pointer can get out-of-bounds causing all kinds of mayhem.
> >
> > Not sure why this should be a problem without delving into the S390
> > code. After all, x86 has 2, 3, or 4 levels as well (at compile time) in
> > a way that's transparent to the walker.
>
> Its hard to understand without looking at the s390 details. The main
> difference between x86 and s390 in that respect is that on s390 the
> number of page table levels is determined at runtime on a per process
> basis. A compat process uses 2 levels, a 64 bit process starts with 3
> levels and can "upgrade" to 4 levels if something gets mapped above
> 4TB. Which means that a *pgd can point to a region-second (2**53 bytes),
> a region-third (2**42 bytes) or a segment table (2**31 bytes), a *pud
> can point to a region-third or a segment table. The page table
> primitives know about this semantic, in particular pud_offset and
> pmd_offset check the type of the page table pointed to by *pgd and *pud
> and do nothing with the pointer if it is a lower level page table.
> The only operation I can not "patch" is the pgd++/pud++ operation.
So in short, sometimes a pgd_t isn't really a pgd_t at all. It's another
object with different semantics that generic code can trip over.
Can I get you to explain why this is necessary or even preferable to
doing it the generic way where pgd_t has a fixed software meaning
regardless of how many hardware levels are in play?
--
http://selenic.com : development and support for Mercurial and Linux
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 01/10] Documentation
From: Vivek Goyal @ 2009-03-12 14:09 UTC (permalink / raw)
To: Peter Zijlstra
Cc: oz-kernel-H+wXaHxf7aLQT0dZR+AlfA,
paolo.valente-rcYM44yAMweonA0d6jMUrA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dhaval-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
menage-hpIqsD4AKlfQT0dZR+AlfA, jmoyer-H+wXaHxf7aLQT0dZR+AlfA,
fchecconi-Re5JQEeQqe8AvxtiuMwx3w, arozansk-H+wXaHxf7aLQT0dZR+AlfA,
jens.axboe-QHcLZuEGTsvQT0dZR+AlfA,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
fernando-w0OK63jvRlAuJ+9fw/WgBHgSJqDPrsil,
balbir-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
In-Reply-To: <1236853490.5090.140.camel@laptop>
On Thu, Mar 12, 2009 at 11:24:50AM +0100, Peter Zijlstra wrote:
> On Wed, 2009-03-11 at 21:56 -0400, Vivek Goyal wrote:
> > +Going back to old behavior
> > +==========================
> > +In new scheme of things essentially we are creating hierarchical fair
> > +queuing logic in elevator layer and changing IO schedulers to make use of
> > +that logic so that end IO schedulers start supporting hierarchical scheduling.
> > +
> > +Elevator layer continues to support the old interfaces. So even if fair queuing
> > +is enabled at elevator layer, one can have both new hierarchical scheduler as
> > +well as old non-hierarchical scheduler operating.
> > +
> > +Also noop, deadline and AS have option of enabling hierarchical scheduling.
> > +If it is selected, fair queuing is done in hierarchical manner. If hierarchical
> > +scheduling is disabled, noop, deadline and AS should retain their existing
> > +behavior.
> > +
> > +CFQ is the only exception where one can not disable fair queuing as it is
> > +needed for providing fairness among various threads even in non-hierarchical
> > +mode.
> > +
> > +Various user visible config options
> > +===================================
> > +CONFIG_IOSCHED_NOOP_HIER
> > + - Enables hierchical fair queuing in noop. Not selecting this option
> > + leads to old behavior of noop.
> > +
> > +CONFIG_IOSCHED_DEADLINE_HIER
> > + - Enables hierchical fair queuing in deadline. Not selecting this
> > + option leads to old behavior of deadline.
> > +
> > +CONFIG_IOSCHED_AS_HIER
> > + - Enables hierchical fair queuing in AS. Not selecting this option
> > + leads to old behavior of AS.
> > +
> > +CONFIG_IOSCHED_CFQ_HIER
> > + - Enables hierarchical fair queuing in CFQ. Not selecting this option
> > + still does fair queuing among various queus but it is flat and not
> > + hierarchical.
>
> One worry I have is that these are compile time switches. Is there any
> way you can get the old AS/DEADLINE back when these are enabled but
> you're not actively using cgroups?
Hi Peter,
In principle, if one is not using cgroups, there is only one io queue
in the root group and most likely we should achieve the same behavior
as old schedulers. Just that some extra code gets into execution at
runtime.
I have not got a chance yet to do some numbers but I think this path
can be optimized enough that at run time effectively we don't see any
significant performance penalty and behavior of schedulers is almost
same as old ones.
Thanks
Vivek
^ permalink raw reply
* Re: [RFC v2: Patch 1/3] net: hand off skb list to other cpu to submit to upper layer
From: Ben Hutchings @ 2009-03-12 14:08 UTC (permalink / raw)
To: Zhang, Yanmin
Cc: Andi Kleen, netdev, LKML, herbert, jesse.brandeburg, shemminger,
David Miller
In-Reply-To: <1236845792.2567.484.camel@ymzhang>
On Thu, 2009-03-12 at 16:16 +0800, Zhang, Yanmin wrote:
> On Wed, 2009-03-11 at 12:13 +0100, Andi Kleen wrote:
[...]
> > and just use the hash function on the
> > NIC.
> Sorry. I can't understand what the hash function of NIC is. Perhaps NIC hardware has something
> like hash function to decide the RX queue number based on SRC/DST?
Yes, that's exactly what they do. This feature is sometimes called
Receive-Side Scaling (RSS) which is Microsoft's name for it. Microsoft
requires Windows drivers performing RSS to provide the hash value to the
networking stack, so Linux drivers for the same hardware should be able
to do so too.
> > Have you considered this for forwarding too?
> Yes. originally, I plan to add a tx_num under the same sysfs directory, so admin could
> define that all packets received from a RX queue should be sent out from a specific TX queue.
The choice of TX queue can be based on the RX hash so that configuration
is usually unnecessary.
> So struct sk_buff->queue_mapping would be a union of 2 sub-members, rx_num and tx_num. But
> sk_buff->queue_mapping is just a u16 which is a small type. We might use the most-significant
> bit of sk_buff->queue_mapping as a flag as rx_num and tx_num wouldn't exist at the
> same time.
>
> > The trick here would
> > be to try to avoid reordering inside streams as far as possible,
> It's not to solve reorder issue. The start point is 10G NIC is very fast. We need some cpu
> work on packet receiving dedicately. If they work on other things, NIC might drop packets
> quickly.
Aggressive power-saving causes far greater latency than context-
switching under Linux. I believe most 10G NICs have large RX FIFOs to
mitigate against this. Ethernet flow control also helps to prevent
packet loss.
> The sysfs interface is just to facilitate NIC drivers. If there is no the sysfs interface,
> driver developers need implement it with parameters which are painful.
[...]
Or through the ethtool API, which already has some multiqueue control
operations.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH 01/10] Documentation
From: Vivek Goyal @ 2009-03-12 14:04 UTC (permalink / raw)
To: Dhaval Giani
Cc: nauman, dpshah, lizf, mikew, fchecconi, paolo.valente, jens.axboe,
ryov, fernando, s-uchida, taka, guijianfeng, arozansk, jmoyer,
oz-kernel, balbir, linux-kernel, containers, akpm, menage, peterz
In-Reply-To: <20090312100054.GA8024@linux.vnet.ibm.com>
On Thu, Mar 12, 2009 at 03:30:54PM +0530, Dhaval Giani wrote:
> On Wed, Mar 11, 2009 at 09:56:46PM -0400, Vivek Goyal wrote:
> > o Documentation for io-controller.
> >
> > Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
> > ---
> > Documentation/block/io-controller.txt | 221 +++++++++++++++++++++++++++++++++
> > 1 files changed, 221 insertions(+), 0 deletions(-)
> > create mode 100644 Documentation/block/io-controller.txt
> >
> > diff --git a/Documentation/block/io-controller.txt b/Documentation/block/io-controller.txt
> > new file mode 100644
> > index 0000000..8884c5a
> > --- /dev/null
> > +++ b/Documentation/block/io-controller.txt
> > @@ -0,0 +1,221 @@
> > + IO Controller
> > + =============
> > +
> > +Overview
> > +========
> > +
> > +This patchset implements a proportional weight IO controller. That is one
> > +can create cgroups and assign prio/weights to those cgroups and task group
> > +will get access to disk proportionate to the weight of the group.
> > +
> > +These patches modify elevator layer and individual IO schedulers to do
> > +IO control hence this io controller works only on block devices which use
> > +one of the standard io schedulers can not be used with any xyz logical block
> > +device.
> > +
> > +The assumption/thought behind modifying IO scheduler is that resource control
> > +is needed only on leaf nodes where the actual contention for resources is
> > +present and not on intertermediate logical block devices.
> > +
> > +Consider following hypothetical scenario. Lets say there are three physical
> > +disks, namely sda, sdb and sdc. Two logical volumes (lv0 and lv1) have been
> > +created on top of these. Some part of sdb is in lv0 and some part is in lv1.
> > +
> > + lv0 lv1
> > + / \ / \
> > + sda sdb sdc
> > +
> > +Also consider following cgroup hierarchy
> > +
> > + root
> > + / \
> > + A B
> > + / \ / \
> > + T1 T2 T3 T4
> > +
> > +A and B are two cgroups and T1, T2, T3 and T4 are tasks with-in those cgroups.
> > +Assuming T1, T2, T3 and T4 are doing IO on lv0 and lv1. These tasks should
> > +get their fair share of bandwidth on disks sda, sdb and sdc. There is no
> > +IO control on intermediate logical block nodes (lv0, lv1).
> > +
> > +So if tasks T1 and T2 are doing IO on lv0 and T3 and T4 are doing IO on lv1
> > +only, there will not be any contetion for resources between group A and B if
> > +IO is going to sda or sdc. But if actual IO gets translated to disk sdb, then
> > +IO scheduler associated with the sdb will distribute disk bandwidth to
> > +group A and B proportionate to their weight.
> > +
> > +CFQ already has the notion of fairness and it provides differential disk
> > +access based on priority and class of the task. Just that it is flat and
> > +with cgroup stuff, it needs to be made hierarchical.
> > +
> > +Rest of the IO schedulers (noop, deadline and AS) don't have any notion
> > +of fairness among various threads.
> > +
> > +One of the concerns raised with modifying IO schedulers was that we don't
> > +want to replicate the code in all the IO schedulers. These patches share
> > +the fair queuing code which has been moved to a common layer (elevator
> > +layer). Hence we don't end up replicating code across IO schedulers.
> > +
> > +Design
> > +======
> > +This patchset primarily uses BFQ (Budget Fair Queuing) code to provide
> > +fairness among different IO queues. Fabio and Paolo implemented BFQ which uses
> > +B-WF2Q+ algorithm for fair queuing.
> > +
> > +Why BFQ?
> > +
> > +- Not sure if weighted round robin logic of CFQ can be easily extended for
> > + hierarchical mode. One of the things is that we can not keep dividing
> > + the time slice of parent group among childrens. Deeper we go in hierarchy
> > + time slice will get smaller.
> > +
> > + One of the ways to implement hierarchical support could be to keep track
> > + of virtual time and service provided to queue/group and select a queue/group
> > + for service based on any of the various available algoriths.
> > +
> > + BFQ already had support for hierarchical scheduling, taking those patches
> > + was easier.
> > +
> > +- BFQ was designed to provide tighter bounds/delay w.r.t service provided
> > + to a queue. Delay/Jitter with BFQ is supposed to be O(1).
> > +
> > + Note: BFQ originally used amount of IO done (number of sectors) as notion
> > + of service provided. IOW, it tried to provide fairness in terms of
> > + actual IO done and not in terms of actual time disk access was
> > + given to a queue.
> > +
> > + This patcheset modified BFQ to provide fairness in time domain because
> > + that's what CFQ does. So idea was try not to deviate too much from
> > + the CFQ behavior initially.
> > +
> > + Providing fairness in time domain makes accounting trciky because
> > + due to command queueing, at one time there might be multiple requests
> > + from different queues and there is no easy way to find out how much
> > + disk time actually was consumed by the requests of a particular
> > + queue. More about this in comments in source code.
> > +
> > +So it is yet to be seen if changing to time domain still retains BFQ gurantees
> > +or not.
> > +
> > +From data structure point of view, one can think of a tree per device, where
> > +io groups and io queues are hanging and are being scheduled using B-WF2Q+
> > +algorithm. io_queue, is end queue where requests are actually stored and
> > +dispatched from (like cfqq).
> > +
> > +These io queues are primarily created by and managed by end io schedulers
> > +depending on its semantics. For example, noop, deadline and AS ioschedulers
> > +keep one io queues per cgroup and cfqq keeps one io queue per io_context in
> > +a cgroup (apart from async queues).
> > +
> > +A request is mapped to an io group by elevator layer and which io queue it
> > +is mapped to with in group depends on ioscheduler. Currently "current" task
> > +is used to determine the cgroup (hence io group) of the request. Down the
> > +line we need to make use of bio-cgroup patches to map delayed writes to
> > +right group.
> > +
> > +Going back to old behavior
> > +==========================
> > +In new scheme of things essentially we are creating hierarchical fair
> > +queuing logic in elevator layer and chaning IO schedulers to make use of
> > +that logic so that end IO schedulers start supporting hierarchical scheduling.
> > +
> > +Elevator layer continues to support the old interfaces. So even if fair queuing
> > +is enabled at elevator layer, one can have both new hierchical scheduler as
> > +well as old non-hierarchical scheduler operating.
> > +
> > +Also noop, deadline and AS have option of enabling hierarchical scheduling.
> > +If it is selected, fair queuing is done in hierarchical manner. If hierarchical
> > +scheduling is disabled, noop, deadline and AS should retain their existing
> > +behavior.
> > +
> > +CFQ is the only exception where one can not disable fair queuing as it is
> > +needed for provding fairness among various threads even in non-hierarchical
> > +mode.
> > +
> > +Various user visible config options
> > +===================================
> > +CONFIG_IOSCHED_NOOP_HIER
> > + - Enables hierchical fair queuing in noop. Not selecting this option
> > + leads to old behavior of noop.
> > +
> > +CONFIG_IOSCHED_DEADLINE_HIER
> > + - Enables hierchical fair queuing in deadline. Not selecting this
> > + option leads to old behavior of deadline.
> > +
> > +CONFIG_IOSCHED_AS_HIER
> > + - Enables hierchical fair queuing in AS. Not selecting this option
> > + leads to old behavior of AS.
> > +
> > +CONFIG_IOSCHED_CFQ_HIER
> > + - Enables hierarchical fair queuing in CFQ. Not selecting this option
> > + still does fair queuing among various queus but it is flat and not
> > + hierarchical.
> > +
> > +Config options selected automatically
> > +=====================================
> > +These config options are not user visible and are selected/deselected
> > +automatically based on IO scheduler configurations.
> > +
> > +CONFIG_ELV_FAIR_QUEUING
> > + - Enables/Disables the fair queuing logic at elevator layer.
> > +
> > +CONFIG_GROUP_IOSCHED
> > + - Enables/Disables hierarchical queuing and associated cgroup bits.
> > +
> > +TODO
> > +====
> > +- Lots of cleanups, testing, bug fixing, optimizations, benchmarking etc...
> > +- Convert cgroup ioprio to notion of weight.
> > +- Anticipatory code will need more work. It is not working properly currently
> > + and needs more thought.
> > +- Use of bio-cgroup patches.
> > +- Use of Nauman's per cgroup request descriptor patches.
> > +
> > +HOWTO
> > +=====
> > +So far I have done very simple testing of running two dd threads in two
> > +different cgroups. Here is what you can do.
> > +
> > +- Enable hierarchical scheduling in io scheuduler of your choice (say cfq).
> > + CONFIG_IOSCHED_CFQ_HIER=y
> > +
> > +- Compile and boot into kernel and mount IO controller.
> > +
> > + mount -t cgroup -o io none /cgroup
> > +
> > +- Create two cgroups
> > + mkdir -p /cgroup/test1/ /cgroup/test2
> > +
> > +- Set io priority of group test1 and test2
> > + echo 0 > /cgroup/test1/io.ioprio
> > + echo 4 > /cgroup/test2/io.ioprio
> > +
> > +- Create two same size files (say 512MB each) on same disk (file1, file2) and
> > + launch two dd threads in different cgroup to read those files. Make sure
> > + right io scheduler is being used for the block device where files are
> > + present (the one you compiled in hierarchical mode).
> > +
> > + echo 1 > /proc/sys/vm/drop_caches
> > +
> > + dd if=/mnt/lv0/zerofile1 of=/dev/null &
> > + echo $! > /cgroup/test1/tasks
> > + cat /cgroup/test1/tasks
> > +
> > + dd if=/mnt/lv0/zerofile2 of=/dev/null &
> > + echo $! > /cgroup/test2/tasks
> > + cat /cgroup/test2/tasks
> > +
> > +- First dd should finish first.
> > +
> > +Some Test Results
> > +=================
> > +- Two dd in two cgroups with prio 0 and 4. Ran two "dd" in those cgroups.
> > +
> > +234179072 bytes (234 MB) copied, 10.1811 s, 23.0 MB/s
> > +234179072 bytes (234 MB) copied, 12.6187 s, 18.6 MB/s
> > +
> > +- Three dd in three cgroups with prio 0, 4, 4.
> > +
> > +234179072 bytes (234 MB) copied, 13.7654 s, 17.0 MB/s
> > +234179072 bytes (234 MB) copied, 19.476 s, 12.0 MB/s
> > +234179072 bytes (234 MB) copied, 20.1858 s, 11.6 MB/s
>
> Hi Vivek,
>
> I would be interested in knowing if these are the results expected?
>
Hi Dhaval,
Good question. Keeping current expectation in mind, yes these are expected
results. To begin with, current expectations are that try to emulate
cfq behavior and the kind of service differentiation we get between
threads of different priority, same kind of service differentiation we
should get from different cgroups.
Having said that, in theory a more accurate estimate should be amount
of actual disk time a queue/cgroup got. I have put a tracing message
to keep track of total service received by a queue. If you run "blktrace"
then you can see that. Ideally, total service received by two threads
over a period of time should be in same proportion as their cgroup
weights.
It will not be easy to achive it given the constraints we have got in
terms of how to accurately we can account for disk time actually used by a
queue in certain situations. So to begin with I am targetting that
try to meet same kind of service differentation between cgroups as
cfq provides between threads and then slowly refine it to see how
close one can come to get accurate numbers in terms of "total_serivce"
received by each queue.
Thanks
Vivek
^ permalink raw reply
* Re: feature-removal-schedule.txt for some I2C functions
From: Jean Delvare @ 2009-03-12 14:06 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: LKML
In-Reply-To: <20090312102617.3235a35b@pedra.chehab.org>
Hi Mauro,
On Thu, 12 Mar 2009 10:26:17 -0300, Mauro Carvalho Chehab wrote:
> Hi Jean,
>
> On your entry at Documentation/feature-removal-schedule.txt:
>
> What: i2c_attach_client(), i2c_detach_client(), i2c_driver->detach_client()
> When: 2.6.29 (ideally) or 2.6.30 (more likely)
> Why: Deprecated by the new (standard) device driver binding model. Use
> i2c_driver->probe() and ->remove() instead.
> Who: Jean Delvare <khali@linux-fr.org>
>
> You forgot to add a check entry, like:
> Check: i2c_attach_client i2c_detach_client i2c_driver->detach_client
>
> The check entry is used by checkpatch.pl to warn about the usage of a legacy function.
>
> Please fix it, since me and others rely on this tool to discover about the
> usage of legacy functions.
Thanks for the tip, I didn't know about this. Is there some
documentation about the Check: entry format? If checkpatch.pl simply
matches the strings then i2c_driver->detach_client is never going to
match, so there's no point in adding it.
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH] dnet: Dave DNET ethernet controller driver
From: David Miller @ 2009-03-12 14:05 UTC (permalink / raw)
To: mboards; +Cc: shemminger, yanok, linux-arm-kernel, netdev, s.hauer, wd, dzu
In-Reply-To: <F884D8C3-E35B-4239-8D72-165EE528FCAC@prograde.net>
From: Michael Cashwell <mboards@prograde.net>
Date: Thu, 12 Mar 2009 09:41:38 -0400
> I'm confused by this. If I'm NFS-booting the board then how do I get
> to those userland tools if I don't have a valid MAC address in place
> to do the root mount?
Initial ramdisk.
^ permalink raw reply
* Re: ELF bugfixes
From: David Miller @ 2009-03-12 14:05 UTC (permalink / raw)
To: phcoder; +Cc: grub-devel
In-Reply-To: <49B91197.6050008@gmail.com>
From: phcoder <phcoder@gmail.com>
Date: Thu, 12 Mar 2009 14:43:51 +0100
> Actually what I was doing now was discussing. If we don't discuss we
> may everyone create our own fork. I previously had problems because
> some of the structures in headers didn't have proper alignment
> attribute. My problem was that grub2 didn't load solaris
> kernel. Further it revealed that the problem wasn't the
> attributes. I fixed the problem (see the rest of my patch) however I
> decided to submit also that part to prevent potential problems in
> the future. If you're expert with ELF format and say that this part
> will never be needed, it's ok with me but please stay respectful and
> discuss instead of accusing.
Your type attribute changes look arbitrary because you do not attach
appropriate detailed descriptions as to why you are making them.
They really aren't needed on any system.
If you require them to get things working, there is likely a problem
elsehwere.
^ permalink raw reply
* Re: [PATCH 01/10] Documentation
From: Vivek Goyal @ 2009-03-12 14:04 UTC (permalink / raw)
To: Dhaval Giani
Cc: oz-kernel-H+wXaHxf7aLQT0dZR+AlfA,
paolo.valente-rcYM44yAMweonA0d6jMUrA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
menage-hpIqsD4AKlfQT0dZR+AlfA, jmoyer-H+wXaHxf7aLQT0dZR+AlfA,
fchecconi-Re5JQEeQqe8AvxtiuMwx3w, arozansk-H+wXaHxf7aLQT0dZR+AlfA,
jens.axboe-QHcLZuEGTsvQT0dZR+AlfA,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
fernando-w0OK63jvRlAuJ+9fw/WgBHgSJqDPrsil,
balbir-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
In-Reply-To: <20090312100054.GA8024-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
On Thu, Mar 12, 2009 at 03:30:54PM +0530, Dhaval Giani wrote:
> On Wed, Mar 11, 2009 at 09:56:46PM -0400, Vivek Goyal wrote:
> > o Documentation for io-controller.
> >
> > Signed-off-by: Vivek Goyal <vgoyal-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > ---
> > Documentation/block/io-controller.txt | 221 +++++++++++++++++++++++++++++++++
> > 1 files changed, 221 insertions(+), 0 deletions(-)
> > create mode 100644 Documentation/block/io-controller.txt
> >
> > diff --git a/Documentation/block/io-controller.txt b/Documentation/block/io-controller.txt
> > new file mode 100644
> > index 0000000..8884c5a
> > --- /dev/null
> > +++ b/Documentation/block/io-controller.txt
> > @@ -0,0 +1,221 @@
> > + IO Controller
> > + =============
> > +
> > +Overview
> > +========
> > +
> > +This patchset implements a proportional weight IO controller. That is one
> > +can create cgroups and assign prio/weights to those cgroups and task group
> > +will get access to disk proportionate to the weight of the group.
> > +
> > +These patches modify elevator layer and individual IO schedulers to do
> > +IO control hence this io controller works only on block devices which use
> > +one of the standard io schedulers can not be used with any xyz logical block
> > +device.
> > +
> > +The assumption/thought behind modifying IO scheduler is that resource control
> > +is needed only on leaf nodes where the actual contention for resources is
> > +present and not on intertermediate logical block devices.
> > +
> > +Consider following hypothetical scenario. Lets say there are three physical
> > +disks, namely sda, sdb and sdc. Two logical volumes (lv0 and lv1) have been
> > +created on top of these. Some part of sdb is in lv0 and some part is in lv1.
> > +
> > + lv0 lv1
> > + / \ / \
> > + sda sdb sdc
> > +
> > +Also consider following cgroup hierarchy
> > +
> > + root
> > + / \
> > + A B
> > + / \ / \
> > + T1 T2 T3 T4
> > +
> > +A and B are two cgroups and T1, T2, T3 and T4 are tasks with-in those cgroups.
> > +Assuming T1, T2, T3 and T4 are doing IO on lv0 and lv1. These tasks should
> > +get their fair share of bandwidth on disks sda, sdb and sdc. There is no
> > +IO control on intermediate logical block nodes (lv0, lv1).
> > +
> > +So if tasks T1 and T2 are doing IO on lv0 and T3 and T4 are doing IO on lv1
> > +only, there will not be any contetion for resources between group A and B if
> > +IO is going to sda or sdc. But if actual IO gets translated to disk sdb, then
> > +IO scheduler associated with the sdb will distribute disk bandwidth to
> > +group A and B proportionate to their weight.
> > +
> > +CFQ already has the notion of fairness and it provides differential disk
> > +access based on priority and class of the task. Just that it is flat and
> > +with cgroup stuff, it needs to be made hierarchical.
> > +
> > +Rest of the IO schedulers (noop, deadline and AS) don't have any notion
> > +of fairness among various threads.
> > +
> > +One of the concerns raised with modifying IO schedulers was that we don't
> > +want to replicate the code in all the IO schedulers. These patches share
> > +the fair queuing code which has been moved to a common layer (elevator
> > +layer). Hence we don't end up replicating code across IO schedulers.
> > +
> > +Design
> > +======
> > +This patchset primarily uses BFQ (Budget Fair Queuing) code to provide
> > +fairness among different IO queues. Fabio and Paolo implemented BFQ which uses
> > +B-WF2Q+ algorithm for fair queuing.
> > +
> > +Why BFQ?
> > +
> > +- Not sure if weighted round robin logic of CFQ can be easily extended for
> > + hierarchical mode. One of the things is that we can not keep dividing
> > + the time slice of parent group among childrens. Deeper we go in hierarchy
> > + time slice will get smaller.
> > +
> > + One of the ways to implement hierarchical support could be to keep track
> > + of virtual time and service provided to queue/group and select a queue/group
> > + for service based on any of the various available algoriths.
> > +
> > + BFQ already had support for hierarchical scheduling, taking those patches
> > + was easier.
> > +
> > +- BFQ was designed to provide tighter bounds/delay w.r.t service provided
> > + to a queue. Delay/Jitter with BFQ is supposed to be O(1).
> > +
> > + Note: BFQ originally used amount of IO done (number of sectors) as notion
> > + of service provided. IOW, it tried to provide fairness in terms of
> > + actual IO done and not in terms of actual time disk access was
> > + given to a queue.
> > +
> > + This patcheset modified BFQ to provide fairness in time domain because
> > + that's what CFQ does. So idea was try not to deviate too much from
> > + the CFQ behavior initially.
> > +
> > + Providing fairness in time domain makes accounting trciky because
> > + due to command queueing, at one time there might be multiple requests
> > + from different queues and there is no easy way to find out how much
> > + disk time actually was consumed by the requests of a particular
> > + queue. More about this in comments in source code.
> > +
> > +So it is yet to be seen if changing to time domain still retains BFQ gurantees
> > +or not.
> > +
> > +From data structure point of view, one can think of a tree per device, where
> > +io groups and io queues are hanging and are being scheduled using B-WF2Q+
> > +algorithm. io_queue, is end queue where requests are actually stored and
> > +dispatched from (like cfqq).
> > +
> > +These io queues are primarily created by and managed by end io schedulers
> > +depending on its semantics. For example, noop, deadline and AS ioschedulers
> > +keep one io queues per cgroup and cfqq keeps one io queue per io_context in
> > +a cgroup (apart from async queues).
> > +
> > +A request is mapped to an io group by elevator layer and which io queue it
> > +is mapped to with in group depends on ioscheduler. Currently "current" task
> > +is used to determine the cgroup (hence io group) of the request. Down the
> > +line we need to make use of bio-cgroup patches to map delayed writes to
> > +right group.
> > +
> > +Going back to old behavior
> > +==========================
> > +In new scheme of things essentially we are creating hierarchical fair
> > +queuing logic in elevator layer and chaning IO schedulers to make use of
> > +that logic so that end IO schedulers start supporting hierarchical scheduling.
> > +
> > +Elevator layer continues to support the old interfaces. So even if fair queuing
> > +is enabled at elevator layer, one can have both new hierchical scheduler as
> > +well as old non-hierarchical scheduler operating.
> > +
> > +Also noop, deadline and AS have option of enabling hierarchical scheduling.
> > +If it is selected, fair queuing is done in hierarchical manner. If hierarchical
> > +scheduling is disabled, noop, deadline and AS should retain their existing
> > +behavior.
> > +
> > +CFQ is the only exception where one can not disable fair queuing as it is
> > +needed for provding fairness among various threads even in non-hierarchical
> > +mode.
> > +
> > +Various user visible config options
> > +===================================
> > +CONFIG_IOSCHED_NOOP_HIER
> > + - Enables hierchical fair queuing in noop. Not selecting this option
> > + leads to old behavior of noop.
> > +
> > +CONFIG_IOSCHED_DEADLINE_HIER
> > + - Enables hierchical fair queuing in deadline. Not selecting this
> > + option leads to old behavior of deadline.
> > +
> > +CONFIG_IOSCHED_AS_HIER
> > + - Enables hierchical fair queuing in AS. Not selecting this option
> > + leads to old behavior of AS.
> > +
> > +CONFIG_IOSCHED_CFQ_HIER
> > + - Enables hierarchical fair queuing in CFQ. Not selecting this option
> > + still does fair queuing among various queus but it is flat and not
> > + hierarchical.
> > +
> > +Config options selected automatically
> > +=====================================
> > +These config options are not user visible and are selected/deselected
> > +automatically based on IO scheduler configurations.
> > +
> > +CONFIG_ELV_FAIR_QUEUING
> > + - Enables/Disables the fair queuing logic at elevator layer.
> > +
> > +CONFIG_GROUP_IOSCHED
> > + - Enables/Disables hierarchical queuing and associated cgroup bits.
> > +
> > +TODO
> > +====
> > +- Lots of cleanups, testing, bug fixing, optimizations, benchmarking etc...
> > +- Convert cgroup ioprio to notion of weight.
> > +- Anticipatory code will need more work. It is not working properly currently
> > + and needs more thought.
> > +- Use of bio-cgroup patches.
> > +- Use of Nauman's per cgroup request descriptor patches.
> > +
> > +HOWTO
> > +=====
> > +So far I have done very simple testing of running two dd threads in two
> > +different cgroups. Here is what you can do.
> > +
> > +- Enable hierarchical scheduling in io scheuduler of your choice (say cfq).
> > + CONFIG_IOSCHED_CFQ_HIER=y
> > +
> > +- Compile and boot into kernel and mount IO controller.
> > +
> > + mount -t cgroup -o io none /cgroup
> > +
> > +- Create two cgroups
> > + mkdir -p /cgroup/test1/ /cgroup/test2
> > +
> > +- Set io priority of group test1 and test2
> > + echo 0 > /cgroup/test1/io.ioprio
> > + echo 4 > /cgroup/test2/io.ioprio
> > +
> > +- Create two same size files (say 512MB each) on same disk (file1, file2) and
> > + launch two dd threads in different cgroup to read those files. Make sure
> > + right io scheduler is being used for the block device where files are
> > + present (the one you compiled in hierarchical mode).
> > +
> > + echo 1 > /proc/sys/vm/drop_caches
> > +
> > + dd if=/mnt/lv0/zerofile1 of=/dev/null &
> > + echo $! > /cgroup/test1/tasks
> > + cat /cgroup/test1/tasks
> > +
> > + dd if=/mnt/lv0/zerofile2 of=/dev/null &
> > + echo $! > /cgroup/test2/tasks
> > + cat /cgroup/test2/tasks
> > +
> > +- First dd should finish first.
> > +
> > +Some Test Results
> > +=================
> > +- Two dd in two cgroups with prio 0 and 4. Ran two "dd" in those cgroups.
> > +
> > +234179072 bytes (234 MB) copied, 10.1811 s, 23.0 MB/s
> > +234179072 bytes (234 MB) copied, 12.6187 s, 18.6 MB/s
> > +
> > +- Three dd in three cgroups with prio 0, 4, 4.
> > +
> > +234179072 bytes (234 MB) copied, 13.7654 s, 17.0 MB/s
> > +234179072 bytes (234 MB) copied, 19.476 s, 12.0 MB/s
> > +234179072 bytes (234 MB) copied, 20.1858 s, 11.6 MB/s
>
> Hi Vivek,
>
> I would be interested in knowing if these are the results expected?
>
Hi Dhaval,
Good question. Keeping current expectation in mind, yes these are expected
results. To begin with, current expectations are that try to emulate
cfq behavior and the kind of service differentiation we get between
threads of different priority, same kind of service differentiation we
should get from different cgroups.
Having said that, in theory a more accurate estimate should be amount
of actual disk time a queue/cgroup got. I have put a tracing message
to keep track of total service received by a queue. If you run "blktrace"
then you can see that. Ideally, total service received by two threads
over a period of time should be in same proportion as their cgroup
weights.
It will not be easy to achive it given the constraints we have got in
terms of how to accurately we can account for disk time actually used by a
queue in certain situations. So to begin with I am targetting that
try to meet same kind of service differentation between cgroups as
cfq provides between threads and then slowly refine it to see how
close one can come to get accurate numbers in terms of "total_serivce"
received by each queue.
Thanks
Vivek
^ permalink raw reply
* Re: git doc build failure on OS X 10.5.6 (Leopard) during xmlto phase
From: Alejandro Riveira Fernández @ 2009-03-12 14:02 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Jay Soffian, Tom Holaday
In-Reply-To: <49B8EF3E.2070208@drmicha.warpmail.net>
El Thu, 12 Mar 2009 12:17:18 +0100
Michael J Gruber <git@drmicha.warpmail.net> escribió:
> Alejandro Riveira venit, vidit, dixit 11.03.2009 21:12:
> >>
> > "Me too" from a Ubuntu 8.10 Box
>
> Following up on this:
> On Fedora 10, I have asciidoc 8.2.5 and docbook 1.7.4 xsl's. For proper
> man and html doc, I have to set DOCBOOK_XSL_172=Yes but leave ASCIIDOC8
> unset! I always forget, though (just like the packagers).
>
> Setting DOCBOOK_XSL_172 shuts off a certain hack which would otherwise
> introduce the notorious .ft in man output.
>
> Setting ASCIIDOC8 would keep _emphasis_ from being transformed into
> <emphasis>emphasis</emphasis>, which means it would end up as literal
> _emphasis_ in man as well as html.
>
> Michael
>
> BTW: Alejandro, please don't cull cc here.
I'm sorry :[
In my defense that was using gmane new service via Pan
Thanks for the explanation on how to workaround the issue
^ permalink raw reply
* Re: kvm-autotest -- introducing kvm_runtest_2
From: Michael Goldish @ 2009-03-12 14:03 UTC (permalink / raw)
To: Ryan Harper; +Cc: KVM List, Uri Lublin
In-Reply-To: <337817070.1631851236866509897.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com>
----- "Ryan Harper" <ryanh@us.ibm.com> wrote:
> * Michael Goldish <mgoldish@redhat.com> [2009-03-12 02:26]:
> >
> > > > Regarding the stepfiles you created for Linux -- I can't help
> much
> > > > with those since I don't have the data. I do believe that if I
> had
> > > the
> > > > data and the stepfiles I could quickly identify the problem, so
> if
> > > you
> > > > think those can be sent to us, I'd like to have them.
> > >
> > > I created a stepfile for RHEL5 and what I'm seeing is that one of
> the
> > > screens I captured in stepmaker ended up having a focus ring
> around
> > > something and on replay the focus isn't there. This situation
> isn't
> > > something that a new algo will fix as you pointed out. I'm
> wondering
> > > if
> > > this is something you've seen. I don't quite understand how it
> would
> > > happen since stepmaker and the replace send the same keystrokes.
> I
> > > also
> > > don't see how in general this can be avoided.
> >
> > The problem sounds familiar. Does the ring appear around one of the
> > GNOME menubars, i.e. around "Applications" or "System"? GNOME seems
> to
> > be somewhat indeterministic with those rings. If you run the
> stepfile
> > several times, you'll notice that in most cases you'll see a focus
> > ring (or no focus ring, I don't quite remember) and the rest of the
> > time you'll get the other case.
>
> Ding Ding Ding! =)
>
> >
> > This can be avoided either with experience, or a good wiki entry on
> > picking the right barriers (which we plan to create). But you don't
> > have to avoid making mistakes with stepmaker -- most types of
> mistakes
> > are fixed very quickly and easily with stepeditor.
>
> yep, used stepeditor to fix; defintely worth documenting where one
> should be invoking stepeditor -- from the steps dir; if you don't run
> it from there, it won't find the steps_data dir =(
Are you absolutely sure about that? That's not the way it's supposed to be. I tried running it on several machines and it worked every time regardless of where I invoked it from. Since it resides in the kvm_runtest_2 dir, I usually just change to that directory and type ./stepeditor.py. Then I use file->open and pick the steps file, and it works.
If you have a very recent version, you should have a dir named "steps_data" under "kvm_runtest_2", right next to "steps". Inside "steps_data" you should have the data dirs. For "steps/RHEL5.steps" the corresponding data dir would be "steps_data/RHEL5.steps_data/".
If you have a slightly older version, you should have the data dirs inside the "steps" dir, next to the stepfiles themselves. For "steps/RHEL5.steps", the corresponding data dir would be "steps/RHEL5.steps_data/".
> I'll have to go back and re-read your email on where to put the
> reference ppm files so one gets the refrence comparision.
The paragraph above applies to the reference comparison as well.
> > The other thing has to do with the ISO files. kvm_runtest has a
> very
> > important feature that we innocently forgot to implement in
> > kvm_runtest_2 -- md5sum verification of the ISO files. This means
> that
> > the framework currently makes no use of the "md5sum" and
> "md5sum_1m"
> > parameters in the config file. This means you might be using
> different
> > ISOs than the ones we made our stepfiles with. In that case I
> wouldn't
> > expect any stepfile to succeed. However, if you used these same
> ISOs
> > with kvm_runtest then they should be fine. In any case, I'll add
> the
> > feature ASAP to the git repository.
>
> Right - I suppose it might be better if the names of the windows iso
> disks matched how MS names them in MSDN, for example, kvm_runtest
> refers
> to Windows2008-x64.iso which doesn't match any name from MSDN, what
> we
> have is:
> en_windows_server_2008_datacenter_enterprise_standard_x64_dvd_X14-26714.iso
This is a very good idea. I wonder how we can find out the MSDN names of the ISOs we have.
BTW, did the ISO you mentioned work with kvm_runtest?
^ permalink raw reply
* Re: [tip:core/futexes] futex: use current->time_slack_ns for rt tasks too
From: Peter Zijlstra @ 2009-03-12 14:02 UTC (permalink / raw)
To: Arjan van de Ven
Cc: mingo, hpa, dvhltc, linux-kernel, rusty, tglx, mingo,
linux-tip-commits
In-Reply-To: <49B913DC.6040807@linux.intel.com>
On Thu, 2009-03-12 at 06:53 -0700, Arjan van de Ven wrote:
> Darren Hart wrote:
> > Commit-ID: 16f4993f4e9860715918efd4eeac928f8de1218b
> > Gitweb: http://git.kernel.org/tip/16f4993f4e9860715918efd4eeac928f8de1218b
> > Author: "Darren Hart" <dvhltc@us.ibm.com>
> > AuthorDate: Thu, 12 Mar 2009 00:55:59 -0700
> > Commit: Ingo Molnar <mingo@elte.hu>
> > CommitDate: Thu, 12 Mar 2009 11:20:57 +0100
> >
> > futex: use current->time_slack_ns for rt tasks too
> >
> > RT tasks should set their timer slack to 0 on their own. This
> > patch removes the 'if (rt_task()) slack = 0;' block in
> > futex_wait.
>
> Hi,
>
> can you explain the rationale for this reasoning?
Yeah, I found it iffy as well, I think we want something like the below
instead though..
---
Subject: sched: adjust timer_slack_ns on scheduler policy change
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date: Thu Mar 12 15:01:02 CET 2009
Ensure RT tasks have 0 timer slack.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
---
kernel/sched.c | 2 ++
1 file changed, 2 insertions(+)
Index: linux-2.6/kernel/sched.c
===================================================================
--- linux-2.6.orig/kernel/sched.c
+++ linux-2.6/kernel/sched.c
@@ -5511,10 +5511,12 @@ __setscheduler(struct rq *rq, struct tas
case SCHED_NORMAL:
case SCHED_BATCH:
case SCHED_IDLE:
+ p->timer_slack_ns = p->default_timer_slack_ns;
p->sched_class = &fair_sched_class;
break;
case SCHED_FIFO:
case SCHED_RR:
+ p->timer_slack_ns = 0;
p->sched_class = &rt_sched_class;
break;
}
^ permalink raw reply
* [PATCH] i.MX31: fix panning, error handling, clean up
From: Guennadi Liakhovetski @ 2009-03-12 14:02 UTC (permalink / raw)
To: linux-kernel; +Cc: Dan Williams, Sascha Hauer, Andrew Morton, adaplas
1. check for errors returned from clk_get()
2. fix "Unbalanced enable for IRQ 160"
3. fix transmit descriptor handling in panning
4. clean frame buffer on blank - useful for OLED displays
5. formatting clean up
Signed-off-by: Guennadi Liakhovetski <lg@denx.de>
---
I was told drivers/video is sort of orphan (cc-ing the official maintainer
in case this is not true), so, don't know to whom I actually shall send
this. Originally the driver went in over Dan's dmaengine tree, so, he is
on CC, the driver is for i.MX3x SoCs, hence Sascha Hauer, as a last
resort, maybe Andrew will agree to take it directly.
drivers/video/mx3fb.c | 56 +++++++++++++++++++++++++++---------------------
1 files changed, 31 insertions(+), 25 deletions(-)
diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
index 3e84635..02014d2 100644
--- a/drivers/video/mx3fb.c
+++ b/drivers/video/mx3fb.c
@@ -400,12 +400,12 @@ static void sdc_disable_channel(struct mx3fb_info *mx3_fbi)
static int sdc_set_window_pos(struct mx3fb_data *mx3fb, enum ipu_channel channel,
int16_t x_pos, int16_t y_pos)
{
- x_pos += mx3fb->h_start_width;
- y_pos += mx3fb->v_start_width;
-
if (channel != IDMAC_SDC_0)
return -EINVAL;
+ x_pos += mx3fb->h_start_width;
+ y_pos += mx3fb->v_start_width;
+
mx3fb_write_reg(mx3fb, (x_pos << 16) | y_pos, SDC_BG_POS);
return 0;
}
@@ -491,11 +491,13 @@ static int sdc_init_panel(struct mx3fb_data *mx3fb, enum ipu_panel panel,
* 2^4 to get fractional part, as long as we stay under ~250MHz and on
* i.MX31 it (HSP_CLK) is <= 178MHz. Currently 128.267MHz
*/
- dev_dbg(mx3fb->dev, "pixel clk = %d\n", pixel_clk);
-
ipu_clk = clk_get(mx3fb->dev, "ipu_clk");
- div = clk_get_rate(ipu_clk) * 16 / pixel_clk;
- clk_put(ipu_clk);
+ if (!IS_ERR(ipu_clk)) {
+ div = clk_get_rate(ipu_clk) * 16 / pixel_clk;
+ clk_put(ipu_clk);
+ } else {
+ div = 0;
+ }
if (div < 0x40) { /* Divider less than 4 */
dev_dbg(mx3fb->dev,
@@ -503,6 +505,9 @@ static int sdc_init_panel(struct mx3fb_data *mx3fb, enum ipu_panel panel,
div = 0x40;
}
+ dev_dbg(mx3fb->dev, "pixel clk = %u, divider %u.%u\n",
+ pixel_clk, div >> 4, (div & 7) * 125);
+
spin_lock_irqsave(&mx3fb->lock, lock_flags);
/*
@@ -515,16 +520,16 @@ static int sdc_init_panel(struct mx3fb_data *mx3fb, enum ipu_panel panel,
/* DI settings */
old_conf = mx3fb_read_reg(mx3fb, DI_DISP_IF_CONF) & 0x78FFFFFF;
old_conf |= sig.datamask_en << DI_D3_DATAMSK_SHIFT |
- sig.clksel_en << DI_D3_CLK_SEL_SHIFT |
- sig.clkidle_en << DI_D3_CLK_IDLE_SHIFT;
+ sig.clksel_en << DI_D3_CLK_SEL_SHIFT |
+ sig.clkidle_en << DI_D3_CLK_IDLE_SHIFT;
mx3fb_write_reg(mx3fb, old_conf, DI_DISP_IF_CONF);
old_conf = mx3fb_read_reg(mx3fb, DI_DISP_SIG_POL) & 0xE0FFFFFF;
old_conf |= sig.data_pol << DI_D3_DATA_POL_SHIFT |
- sig.clk_pol << DI_D3_CLK_POL_SHIFT |
- sig.enable_pol << DI_D3_DRDY_SHARP_POL_SHIFT |
- sig.Hsync_pol << DI_D3_HSYNC_POL_SHIFT |
- sig.Vsync_pol << DI_D3_VSYNC_POL_SHIFT;
+ sig.clk_pol << DI_D3_CLK_POL_SHIFT |
+ sig.enable_pol << DI_D3_DRDY_SHARP_POL_SHIFT |
+ sig.Hsync_pol << DI_D3_HSYNC_POL_SHIFT |
+ sig.Vsync_pol << DI_D3_VSYNC_POL_SHIFT;
mx3fb_write_reg(mx3fb, old_conf, DI_DISP_SIG_POL);
switch (pixel_fmt) {
@@ -721,7 +726,6 @@ static int mx3fb_set_par(struct fb_info *fbi)
struct idmac_channel *ichan = mx3_fbi->idmac_channel;
struct idmac_video_param *video = &ichan->params.video;
struct scatterlist *sg = mx3_fbi->sg;
- size_t screen_size;
dev_dbg(mx3fb->dev, "%s [%c]\n", __func__, list_empty(&ichan->queue) ? '-' : '+');
@@ -745,12 +749,10 @@ static int mx3fb_set_par(struct fb_info *fbi)
}
}
- screen_size = fbi->fix.line_length * fbi->var.yres;
-
sg_init_table(&sg[0], 1);
sg_init_table(&sg[1], 1);
- sg_dma_address(&sg[0]) = fbi->fix.smem_start;
+ sg_dma_address(&sg[0]) = fbi->fix.smem_start;
sg_set_page(&sg[0], virt_to_page(fbi->screen_base),
fbi->fix.smem_len,
offset_in_page(fbi->screen_base));
@@ -927,7 +929,7 @@ static int mx3fb_setcolreg(unsigned int regno, unsigned int red,
u32 val;
int ret = 1;
- dev_dbg(fbi->device, "%s\n", __func__);
+ dev_dbg(fbi->device, "%s, regno = %u\n", __func__, regno);
mutex_lock(&mx3_fbi->mutex);
/*
@@ -973,9 +975,8 @@ static int mx3fb_blank(int blank, struct fb_info *fbi)
struct mx3fb_info *mx3_fbi = fbi->par;
struct mx3fb_data *mx3fb = mx3_fbi->mx3fb;
- dev_dbg(fbi->device, "%s\n", __func__);
-
- dev_dbg(fbi->device, "blank = %d\n", blank);
+ dev_dbg(fbi->device, "%s, blank = %d, base %p, len %u\n", __func__,
+ blank, fbi->screen_base, fbi->fix.smem_len);
if (mx3_fbi->blank == blank)
return 0;
@@ -988,8 +989,11 @@ static int mx3fb_blank(int blank, struct fb_info *fbi)
case FB_BLANK_VSYNC_SUSPEND:
case FB_BLANK_HSYNC_SUSPEND:
case FB_BLANK_NORMAL:
- sdc_disable_channel(mx3_fbi);
sdc_set_brightness(mx3fb, 0);
+ memset((char *)fbi->screen_base, 0, fbi->fix.smem_len);
+ /* Give LCD time to update - enough for 50 and 60 Hz */
+ msleep(25);
+ sdc_disable_channel(mx3_fbi);
break;
case FB_BLANK_UNBLANK:
sdc_enable_channel(mx3_fbi);
@@ -1063,6 +1067,7 @@ static int mx3fb_pan_display(struct fb_var_screeninfo *var,
mutex_unlock(&mx3_fbi->mutex);
dev_info(fbi->device, "Panning failed due to %s\n", ret < 0 ?
"user interrupt" : "timeout");
+ disable_irq(mx3_fbi->idmac_channel->eof_irq);
return ret ? : -ETIMEDOUT;
}
@@ -1073,6 +1078,9 @@ static int mx3fb_pan_display(struct fb_var_screeninfo *var,
virt_to_page(fbi->screen_base + offset), fbi->fix.smem_len,
offset_in_page(fbi->screen_base + offset));
+ if (mx3_fbi->txd)
+ async_tx_ack(mx3_fbi->txd);
+
txd = dma_chan->device->device_prep_slave_sg(dma_chan, sg +
mx3_fbi->cur_ipu_buf, 1, DMA_TO_DEVICE, DMA_PREP_INTERRUPT);
if (!txd) {
@@ -1099,8 +1107,6 @@ static int mx3fb_pan_display(struct fb_var_screeninfo *var,
return -EIO;
}
- if (mx3_fbi->txd)
- async_tx_ack(mx3_fbi->txd);
mx3_fbi->txd = txd;
fbi->var.xoffset = var->xoffset;
@@ -1506,7 +1512,7 @@ static struct platform_driver mx3fb_driver = {
* example:
* video=mx3fb:bpp=16
*/
-static int mx3fb_setup(void)
+static int __init mx3fb_setup(void)
{
#ifndef MODULE
char *opt, *options = NULL;
--
1.5.4
^ permalink raw reply related
* nfs clients crashes
From: Bas van der Vlies @ 2009-03-12 13:55 UTC (permalink / raw)
To: linux-nfs@vger.kernel.org
OS: debian lenny
kernel release tested: 2.6.28.[1-7] , 2.6.29.rc5 and 2.6.29.rc7
NFS-server: solaris 10 zfs/nfs server
Is this a familiar bug?
{{{
------------[ cut here ]------------
kernel BUG at fs/nfs/write.c:252!
invalid opcode: 0000 [#1] SMP
last sysfs file: /sys/class/infiniband/mlx4_0/ports/1/gids/0
CPU 2
Modules linked in: ipmi_devintf ipmi_si ipmi_msghandler autofs4 fuse
dm_snapshot dm_mirror dm_region_hash dm_log dm_mod mptctl rdma_ucm rdma_cm
iw_cm ib_addr ib_ipoib inet_lro ib_ucm ib_cm ib_sa ib_uverbs ib_umad
mlx4_ib ib_mad ib_core dcdbas ehci_hcd uhci_hcd mlx4_core bnx2 crc32
Pid: 262, comm: pdflush Not tainted 2.6.28.7-sara1 #1
RIP: 0010:[<ffffffff80309107>] [<ffffffff80309107>]
nfs_do_writepage+0x107/0x1a0
RSP: 0000:ffff88043e0f7b10 EFLAGS: 00010202
RAX: 0000000000000001 RBX: ffffe2000e5c63e8 RCX: 0000000000000015
RDX: 0000000000000000 RSI: 0000000000600020 RDI: ffff8804354a7550
RBP: ffff88043e0f7b40 R08: ffff880435597268 R09: ffff8804386ea140
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8804386ea140
R13: ffff8804354a769c R14: ffffe2000e5c63e8 R15: ffff8804354a75e8
FS: 0000000000000000(0000) GS:ffff88043f846840(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 000000005555c18c CR3: 0000000000201000 CR4: 00000000000406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process pdflush (pid: 262, threadinfo ffff88043e0f6000, task ffff88043faf9270)
Stack:
ffff88043e0f7c90 ffffe2000e5c63e8 ffffe2000e5c63e8 ffff88043e0f7be0
0000000000000001 0000000000000002 ffff88043e0f7b60 ffffffff803096a9
ffffe2000e5c63e8 0000000000000001 ffff88043e0f7c80 ffffffff80272707
Call Trace:
[<ffffffff803096a9>] nfs_writepages_callback+0x19/0x30
[<ffffffff80272707>] write_cache_pages+0x227/0x460
[<ffffffff80309690>] ? nfs_writepages_callback+0x0/0x30
[<ffffffff8030adb1>] ? nfs_flush_one+0xb1/0xf0
[<ffffffff80309642>] nfs_writepages+0xa2/0xf0
[<ffffffff8030ad00>] ? nfs_flush_one+0x0/0xf0
[<ffffffff80272998>] do_writepages+0x28/0x50
[<ffffffff802b410b>] __writeback_single_inode+0x9b/0x470
[<ffffffff8022a4e0>] ? update_curr+0xd0/0x120
[<ffffffff8022e658>] ? dequeue_entity+0x18/0x190
[<ffffffff802b4ac0>] generic_sync_sb_inodes+0x3a0/0x4d0
[<ffffffff802b4dae>] writeback_inodes+0x4e/0xf0
[<ffffffff80272b34>] wb_kupdate+0xa4/0x130
[<ffffffff802736be>] pdflush+0x10e/0x1f0
[<ffffffff80272a90>] ? wb_kupdate+0x0/0x130
[<ffffffff802735b0>] ? pdflush+0x0/0x1f0
[<ffffffff8024ba79>] kthread+0x49/0x90
[<ffffffff8020d1b9>] child_rip+0xa/0x11
[<ffffffff8024ba30>] ? kthread+0x0/0x90
[<ffffffff8020d1af>] ? child_rip+0x0/0x11
Code: b4 00 00 00 31 db 48 83 c4 08 89 d8 5b 41 5c 41 5d 41 5e 41 5f c9 c3
0f 1f 44 00 00 41 f6 44 24 40 02 74 0b 41 fe 87 b4 00 00 00 <0f> 0b eb fe
4c 89 f7 e8 2d 8c f6 ff 85 c0 75 72 49 8b 46 18 ba
RIP [<ffffffff80309107>] nfs_do_writepage+0x107/0x1a0
RSP <ffff88043e0f7b10>
---[ end trace 4fac3d44a611662b ]---
}}}
--
********************************************************************
* Bas van der Vlies e-mail: basv-mYZPGKKnAUw@public.gmane.org *
* SARA - Academic Computing Services Amsterdam, The Netherlands *
********************************************************************
^ permalink raw reply
* Re: [PATCH] fix headphone settings and master volume (Conexant CX20551 0x103c30b2)
From: Gregorio Guidi @ 2009-03-12 14:00 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel
In-Reply-To: <s5h7i2v2qcw.wl%tiwai@suse.de>
On Thursday 12 March 2009 07:43:27 Takashi Iwai wrote:
> At Wed, 11 Mar 2009 22:22:39 +0100,
>
> Gregorio Guidi wrote:
> > On Tuesday 10 March 2009 15:49:38 Takashi Iwai wrote:
> > > At Mon, 9 Mar 2009 20:19:35 +0100,
> > >
> > > ...
> > >
> > > Thanks, that helps for debugging.
> > >
> > > Looking through the current patch_conexant.c, there are other messy
> > > codes there, too. So I cleaned up and fixed it on sound git tree
> > > now. Any chance to try it out? The GIT tree is found at:
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
> >
> > I managed to test a kernel snapshot with the latest changes, thanks for
> > taking the time to refactor and clean up the code there.
>
> Thanks for testing.
>
> > There are still issues, though: at the moment, the "Speaker" control does
> > not work. Consequently, automute does not work and Master only controls
> > headphones.
>
> Hm, doesn't "Speaker" give any change if you unplug the headphone?
> It should change the output volume of widget 0x1d. If it's true, there
> can be a few reasons:
>
> A. The real speaker output pin isn't 0x1d but another pin
>
> B. The widget 0x1d has a problem with connection to 0x19
>
> C. The widget 0x1d has no output amp control despite the description
To clarify: the speakers make sounds, but volume control and muting do not
work.
Actually, now that I start to understand how these widget connections work, I
see the problem is simpler: after changing the 0x1d connection (routing the
speakers to 0x19) with {0x1d, AC_VERB_SET_CONNECT_SEL, 0x1}, you have to
update the other places where the 0x1d widget is used (see patch). This also
explains the problem originally reported where Headphone didn't work (here and
in bug #3091).
With just the following patch applied on top of the git tree everything works
nicely (Headphone, Speaker, Master, automute all work as expected).
diff -Nur sound-2.6.git.orig/sound/pci/hda/patch_conexant.c
sound-2.6.git/sound/pci/hda/patch_conexant.c
--- sound-2.6.git.orig/sound/pci/hda/patch_conexant.c 2009-03-12
14:56:20.000000000 +0100
+++ sound-2.6.git/sound/pci/hda/patch_conexant.c 2009-03-12
14:29:48.000000000 +0100
@@ -1196,7 +1196,7 @@
* the headphone jack
*/
bits = (!spec->hp_present && spec->cur_eapd) ? 0 : HDA_AMP_MUTE;
- snd_hda_codec_amp_stereo(codec, 0x1d, HDA_OUTPUT, 0,
+ snd_hda_codec_amp_stereo(codec, 0x1d, HDA_OUTPUT, 0x01,
HDA_AMP_MUTE, bits);
bits = spec->cur_eapd ? 0 : HDA_AMP_MUTE;
snd_hda_codec_amp_stereo(codec, 0x13, HDA_OUTPUT, 0,
@@ -1214,7 +1214,7 @@
AC_VERB_GET_PIN_SENSE, 0) & 0x80000000;
bits = (spec->hp_present || !spec->cur_eapd) ? HDA_AMP_MUTE : 0;
- snd_hda_codec_amp_stereo(codec, 0x1d, HDA_OUTPUT, 0,
+ snd_hda_codec_amp_stereo(codec, 0x1d, HDA_OUTPUT, 0x01,
HDA_AMP_MUTE, bits);
}
@@ -1276,7 +1276,7 @@
};
static struct snd_kcontrol_new cxt5047_hp_spk_mixers[] = {
- HDA_CODEC_VOLUME("Speaker Playback Volume", 0x1d, 0x00, HDA_OUTPUT),
+ HDA_CODEC_VOLUME("Speaker Playback Volume", 0x1d, 0x01, HDA_OUTPUT),
HDA_CODEC_VOLUME("Headphone Playback Volume", 0x13, 0x00, HDA_OUTPUT),
{}
};
^ permalink raw reply
* Re: nfsstat --sleep=#
From: Chuck Lever @ 2009-03-12 14:00 UTC (permalink / raw)
To: Kevin Constantine; +Cc: linux-nfs
In-Reply-To: <49B86744.6060105-P5ys19MLBK/QT0dZR+AlfA@public.gmane.org>
Hi Kevin-
man watch(1)
On Mar 11, 2009, at Mar 11, 2009, 9:37 PM, Kevin Constantine wrote:
> I'd really like to have a way to output the nfsstat counters at
> regular intervals (every 3 seconds) where the output is the
> difference between 3 seconds ago and now. Frequently I'll run a
> test and want to watch the nfs call profile throughout the course of
> the test.
>
> Does something like this already exist?
> Are there objections to seeing a feature like this?
>
> I'm thinking something like:
> nfsstat --sleep=1
>
> nfs v3 call: Server Client
> total: 0 3476
> null: 0 0
> getattr: 0 1679
> setattr: 0 0
> lookup: 0 839
> access: 0 839
> readlink: 0 0
> read: 0 0
> write: 0 0
> create: 0 0
> mkdir: 0 0
> symlink: 0 0
> mknod: 0 0
> remove: 0 0
> rmdir: 0 0
> rename: 0 0
> link: 0 0
> readdir: 0 0
> readdirplus: 0 0
> fsstat: 0 119
> fsinfo: 0 0
> pathconf: 0 0
> commit: 0 0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.