I just downloaded the current git head and started playing with the fair group scheduler. (This is on a dual cpu Mac G5.) I created two groups, "a" and "b". Each of them was left with the default share of 1024. I created three cpu hogs by doing "cat /dev/zero > /dev/null". One hog (pid 2435) was put into group "a", while the other two were put into group "b". After giving them time to settle down, "top" showed the following: 2438 cfriesen 20 0 3800 392 336 R 99.5 0.0 4:02....

Sure, makes sense. Looks like it's some sched/auto-sched tree/branch if I'm reading correctly. Ingo, is there a sched tree that add rculist.h file? If so, one of its users needs to #include it. Patch below. --- From: Randy Dunlap <randy.dunlap@oracle.com> nf_conntrack_helper users rcu hlist functions so it needs to #include rculist.h. linux-next-20080521/net/netfilter/nf_conntrack_helper.c:58: error: implicit declaration of function 'hlist_for_each_entry_rcu' linux-next-20080521...

Hi, For everyone interested, I have put together a patchset containing some "fresh" patches related to suspend and hibernation, on top of 2.6.26-rc3, located at: http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.26-rc3/patches/ Patches 01-06 and 11 have been sent to Len as 2.6.27 material. They have been tested by me for some time (except for the most recent changes in patches 01 and 11) and have not lead to any problems so far. Patches 07-10 are in the Jesse's PCI tree, targeted at 2.6....

Speaking as a former OSS driver maintainer, I always preferred drivers/sound. Though Rene's suggestion (use both sound/ and drivers/sound/) might make sense if the subsystem code is huge -- I supported the drivers/block/ -> block/ code movement for example. Jeff --

Under drivers/media/ it would only generate confusion regarding who's responsible for what. But drivers/sound/ sounds good. The only possible problem that comes into my mind is to check what cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed --

I would certainly personally like drivers/sound more, and the placement at the top level is actually because the sound maintainers wanted it that way, probably to avoid the confusion with the old OSS drivers that used to live in drivers/sound. I forget the exact details. It's been many many years, and there may have been some real technical issues too. But basically sound/ was created when ALSA was first merged, and we had a lot of renames from drivers/sound/xyz to sound/oss/xyz. (It...

That would work, but there's a few alternatives that I think would work even better. The downside with what you suggest is that I'd like the arch-specific include files to be clearly separated (ie I think the naming should be "something/include/something", which makes things clearer. Also, I hate how doing '-Iarch/$(ARCH)' would basically make any random arch/xyz/ subdirectory be a potential location for a header file. I'd hate for the include-path to contain subdirectories that simpl...

Suggestion for sound/drivers: drivers/sound/generic :-) Rene. --

Hi, Does this seem like anything that has even a remote possibility of entering the Kernel? It's not a strict requirement for kmemcheck, but it's extremely nice compared to the 1 Hz timer I've been using till now. (Again, I can put it in my queue for now, but it would be nice to have the necessary Signed-off-bys for when it gets merged. I mean, _if_ it gets merged...) Vegard From: Vegard Nossum <vegard.nossum@gmail.com> Date: Wed, 21 May 2008 22:53:13 +0200 Subject: [PATCH] tasklet...

There is no point in keeping the 8259A enabled if the I/O APIC NMI watchdog has failed and the 8259A is not used to pass through regular timer interrupts. This fixes problems with some systems where some logic gets confused. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> --- patch-2.6.26-rc1-20080505-timer-8259-6 diff -up --recursive --new-file linux-2.6.26-rc1-20080505.macro/arch/x86/kernel/io_apic_32.c linux-2.6.26-rc1-20080505/arch/x86/kernel/io_apic_32.c --- linux-2.6.26-rc...

The local APIC is no longer forced off when "nosmp" has been specified. Correct the message printed. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> --- patch-2.6.26-rc1-20080505-nosmp-apic-0 diff -up --recursive --new-file linux-2.6.26-rc1-20080505.macro/arch/x86/kernel/smpboot.c linux-2.6.26-rc1-20080505/arch/x86/kernel/smpboot.c --- linux-2.6.26-rc1-20080505.macro/arch/x86/kernel/smpboot.c 2008-05-05 02:56:19.000000000 +0000 +++ linux-2.6.26-rc1-20080505/arch/x86/kernel/smpboot....

Disable the 8259A when routing of the timer interrupt through the chip to the local APIC of the primary processor has failed. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> --- patch-2.6.26-rc1-20080505-timer-fasteoi-cleanup-0 diff -up --recursive --new-file linux-2.6.26-rc1-20080505.macro/arch/x86/kernel/io_apic_32.c linux-2.6.26-rc1-20080505/arch/x86/kernel/io_apic_32.c --- linux-2.6.26-rc1-20080505.macro/arch/x86/kernel/io_apic_32.c 2008-05-21 18:51:28.000000000 +0000 +++ linux-...

The code that used to be in do_slow_gettimeoffset() that relied on the IRR bit of the master 8259A PIC for IRQ0 to check the state of the output timer 0 of the PIT is no longer there. As a result, there is no need to use the POLL command to acknowledge the timer interrupt in the "8259A Virtual Wire", except for the NMI watchdog when the i82489DX APIC is used (this is because this particular APIC treats NMIs as level-triggered and keeping the input asserted would keep motherboard NMI sources held off...

thanks. please check the attached patch YH

please drop this patch... YH --

noticed that bootmap_size is shifted already... please use attached patch to see if bootmap is right... YH

AAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHH finally after three weeks I have finished my task of figuring out what the hell Linus did to the kernel to mess me up....... Love or regards you choose.... -- Justin P. Mattock --

Hello everybody, as requested on http://kernelnewbies.org/KernelJanitors/Todo here's a first patch that removes type conversion on kmalloc() (which returns a (void*)): It was done against current linus-git=20 (d40ace0c7b4a329f7d869d0fbf27435543bb2acc, if I'm not mistaken), and looks like that: list_del(&bss->list); local->num_bss_info--; } else { =2D bss =3D (struct hostap_bss_info *) =2D kmalloc(sizeof(*bss), GFP_ATOMIC); + bss =3D kmalloc(sizeof(*bss), GFP_ATO...

I agree, keep things seperate. One mail with patch to fix casts, Thank you, I'll keep an eye on this patch. Philipp: Johannes makes some good points, please address his comments and re-submit the patch with trivial@kernel.org on Cc: if it draws no negative comments it looks good to me to add to the trivial tree. -- Jesper Juhl <jesper.juhl@gmail.com> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html --

mips: Remove board_watchpoint_handler. It is not used anywhere in tree. Signed-off-by: David Daney <ddaney@avtrex.com> --- arch/mips/kernel/traps.c | 6 ------ include/asm-mips/traps.h | 1 - 2 files changed, 0 insertions(+), 7 deletions(-) diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c index f9165d1..6e7e4a2 100644 --- a/arch/mips/kernel/traps.c +++ b/arch/mips/kernel/traps.c @@ -71,7 +71,6 @@ extern asmlinkage void handle_reserved(void); extern int fpu_emu...

Hi, I encountered this comment in kernel/softirq.c: /* Some compilers disobey section attribute on statics when not initialized -- RR */ static DEFINE_PER_CPU(struct tasklet_head, tasklet_vec) = { NULL }; static DEFINE_PER_CPU(struct tasklet_head, tasklet_hi_vec) = { NULL }; So I assume it's the combination of static and whatever section DFINE_PER_CPU puts the variable in which is the problem. However, there's a LOT of these "static DEFINE_PER_CPU" without any initializer in the rest of ...

Ok, first, BUG_ON is wrong. We already know users (ie nommu memory usage reporting) are abusing this interface. Making them blow up is unnecessary. Just give them wrong answers. Issuing a warning might be a good idea for debugging. Second, I'd prefer to keep this sort of debugging code out of SLOB. SLUB is much better suited to debugging allocator abuse. -- Mathematics is the supreme nostalgia of our time. --

I also would prefer to keep this out of SLUB. Set/Clear PageSlab dirties the cacheline and it forces the unlining of kmalloc_large. --

SLUB could add a BUG_ON(!PageCompound ) since we added buffering for order 0 allocs. So only order 1 and higher go through kmalloc large. That should catch the general case. --

Why is it too big? Without your additions it is converting kmallocs inline to get_free_pages(). That results in a simple function call with two constant parameters. The patch touches the page struct uselessly. I think the PageSlab marking is useful for debugging but not for a production kernel. --