The jsm driver fails when you try to use the TIOCSSERIAL ioctl. The reason is that the driver never sets uart_port.uartclk, causing the data received using TIOCGSERIAL to not match the internal state of the driver. This patch fixes this problem by settings the uartclk to the value used by the serial_core (16 times the baud base). Signed-off-by: Len Sorensen <lsorense@csclub.uwaterloo.ca> --- a/drivers/serial/jsm/jsm_tty.c 2007-03-13 15:53:39.000000000 -0400 +++ ...

Why did you remove all Cced people? Anyway I filtered some of them out I can do that, but in that case, I need to know how people (especially those input one) want me to do... regards, -- http://www.fi.muni.cz/~xslaby/ Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E -

From: "Nish Aravamudan" <nish.aravamudan@gmail.com> Figure out if 2.6.20.2 does it too, then please try to git bisect it down further. I took a quick look and the two sparc64 commits between 2.6.20.1 and 2.6.20.2 are benign, a fix for E450 interrupts and a kenvctrld fix which is for a driver for hardware your ultra60 doesn't have. :) There is a decent amount of raid and nfs fixes in here, do you use either? Another commit that might be relevant is: commit ...

Thanks for taking this on. I'm sure Andi has a bunch of ideas on this what about asm-x86/ dir? the asm/ symlink would still point to relevant arch, but the file there could be simply #include <asm-x86/file.h> ? thanks, -chris -

Please use git diff -M for things like this. In fact, even if you weren't a git user, I'd ask you to *become* one just because I think that it's a *lot* more productive if people actually see renames as renames, and will see what - if anything - changed when renaming. The "-M" flag isn't the default, simply because it generates patches that cannot be applied with regular "patch", but for something like this, I think it's practically imperative. The old kind of "remove file" ...

Pavel, I've chased one of the 'Suspend to RAM' resume problems to a specific line in drivers/char/vt.c, see attached 2.6.21-rc3 diff with TRACE_RESUME() instrumentation. The macro scr_writew resolves to '*addr = val', which appears to be causing the problem. I've verified that the pointer is not NULL, but don't know if its really valid. Its pretty tough to tell what is happening, but on a Dell XPS it just hangs. A Dell Precision blinks the keyboard lights. Since I don't know anything about ...

NACK. block device driver should never ever play around with file operations themselves. If you want functionality like the one you have please don't overload the loop driver, but start a new (character) driver doing specificaly what you want. And even then I'm not sure we'd want functionality like this in the mainline tree, but at least we can have an open discussion if it's done properly. -

Applied against v0.30 mainline. It only works on prio +16 to +19. Thanks! -- Al -

I had a look at copy_one_pte(). I cannot see any ioproc_update_page() call, not even for the COW pages. Is it intentional? We can live with a COW page for a considerably long time. How could the IO-PROC. know that a process-ID / user virt. addr. pair refers to the same page? The comment above ioproc_update_page() says that every time when a PTE is created / modified... Thanks, Zoltan Menyhart -

I don't know about CGL, but a unified async notification mechanism _is_ needed. In ~2002, I needed one, and what I ended up with was a Red Hat 2.4 kernel with IO_CMD_POLL hacked in. Five years later, mainline still can't do that. Whether it's syslets, threadlets, io_getevents with networking support, kevents, epoll with kaio support, queued signals, or something else, users don't care, but they need _something_. Please don't ignore the users just because they quote the wrong text. ...

please cut your cc lines next time, thanks. It's not obvious, but utter bullshit. Please go away if you think starting post with quotes from CGL specs is even remotely close to a good idea. -

Dear Community, I think I've encountered a bug with the Linux kernel which results in a complete system lockup and which can be started without root priviliges. It's reproducible with 2.6.20.1 and 2.6.20.2 and only x64_64 seems affected. Here's the code which triggers the bug (originally found by me using an only partly initialized "struct itimerval" structure - hence the strange values in it_interval): -----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<----- #include ...

No. The possible DoS is only when high res timers are enabled, which is not the case in 2.6.20. Looking at the values 140735669863712 = 0x7FFF 939C 0520 We convert second to nanoseconds: 140735669863712 * 1e9 = 0x1DCD 4BC3 6B82 914B 4000 The seconds value is limited to LONG_MAX, but on a 64 bit machine, the 140735669863712 is inside LONG_MAX and we have an multiplication overflow. I'm not sure, how this results in a DoS, but I will look into this tomorrow morning, when I'm more ...

diff --git a/Makefile b/Makefile index d165e80..7d2f304 100644 --- a/Makefile +++ b/Makefile @@ -1,7 +1,7 @@ VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 20 -EXTRAVERSION = .2 +EXTRAVERSION = .3 NAME = Homicidal Dwarf Hamster # *DOCUMENTATION* diff --git a/arch/sparc/kernel/of_device.c b/arch/sparc/kernel/of_device.c index dab6169..798b140 100644 --- a/arch/sparc/kernel/of_device.c +++ b/arch/sparc/kernel/of_device.c @@ -495,7 +495,7 @@ static void __init build_device_resources(struct ...

The only use for the "struct module *" is to display the name of the module. This can be solved by adding a "char mod_name[MODULE_NAME_LEN];" field to "kallsym_iter" and copy the name of the module over, while still holding module_mutex. It would be slightly slower, but safer. We can even change the function's interface, so that it doesn't return a "struct module *" at all, since AFAICS kallsyms is the only user of that function. It will still produce strange artifacts, though. If ...

iter->owner = module_get_kallsym(iter->pos - kallsyms_num_syms, &iter->value, &iter->type, iter->name, sizeof(iter->name)); if (iter->owner == NULL) return 0; /* Label it "global" if it is exported, "local" if not exported. */ iter->type = is_exported(iter->name, iter->owner) ^^^^^^^^^^^ -

... [ 1756.728209] BUG: workqueue leaked lock or atomic: nfsd4/0x00000000/3577 [ 1756.728271] last function: laundromat_main+0x0/0x69 [nfsd] [ 1756.728392] 2 locks held by nfsd4/3577: [ 1756.728435] #0: (client_mutex){--..}, at: [<c1205b88>] mutex_lock+0x8/0xa [ 1756.728679] #1: (&inode->i_mutex){--..}, at: [<c1205b88>] mutex_lock+0x8/0xa [ 1756.728923] [<c1003d57>] show_trace_log_lvl+0x1a/0x30 [ 1756.729015] [<c1003d7f>] show_trace+0x12/0x14 [ 1756.729103] [<c1003e79>] ...

I'm not sure I follow you here. Clocksources have the means to adjust the rate of time progression, mostly to warp the time for things like ntp. The stability or otherwise of the tsc is irrelevant. If you had a clocksource which was explicitly using the rate at which a CPU does work as a timebase, then using the same warping mechanism would Yes, that works. But a clocksource is strictly about measuring the progression of real time, and so doesn't generally measure how much work Well, ...

The current Linux scheduler makes one big assumption: that 1ms of CPU time is the same as any other 1ms of CPU time, and that therefore a process makes the same amount of progress regardless of which particular ms of time it gets. This assumption is wrong now, and will become more wrong as virtualization gets more widely used. It's wrong now, because it fails to take into account of several kinds of missing time: 1. interrupts - time spent in an ISR is accounted to the current ...

The serial_txx9 driver have abused device numbers (major 4, minor 128) if CONFIG_SERIAL_TXX9_STDSERIAL was not set. This patch makes the driver allocate minor numbers from major 204 (Low-density serial ports). I suppose a typical user of this driver set CONFIG_SERIAL_TXX9_STDSERIAL to Y (i.e. use "ttyS0"), so this patch would not cause big compatibility issue. Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp> --- diff --git a/Documentation/devices.txt b/Documentation/devices.txt index ...

Hi, Ok, this was bullshit. Nohz and hrtimers turned off really solve the issue with having to press keys. Seems like the yesterday's check was for the other issue and I just pressed the keys automatically, remembering that I had to. Sorry, -- Tomáš Janoušek, a.k.a. Liskni_si, http://work.lisk.in/ -

Hi, A colleage told me to try this yesterday and if I remember correctly, it did not help. I may try it again because I'm not sure whether it wasn't some other issue thing did not work, but I'm absolutely sure that no matter what these settings are, the machine does not resume or hangs soon after resume (in the case of s2disk). And this is since 2.6.20. 2.6.21 just added the 'wait until keypress'. Regards, -- Tomáš Janoušek, a.k.a. Liskni_si, http://work.lisk.in/ -

WARN_ON(de && de->deleted); is sooo unreliable. Why? proc_lookup remove_proc_entry =========== ================= lock_kernel(); spin_lock(&proc_subdir_lock); [find proc entry] spin_unlock(&proc_subdir_lock); spin_lock(&proc_subdir_lock); [find proc entry] proc_get_inode ============== WARN_ON(de && de->deleted); ... if (!atomic_read(&de->count)) free_proc_entry(de); else de->deleted = 1; So, if you have some strange oops [1], and doesn't ...

thanks. Attached now -- Glauber de Oliveira Costa Red Hat Inc. "Free as in Freedom"

Can you apply the attached patch and report what the kernel says with ACPI turned on? -- tejun

Tiny cleanup: In x86_64, the same functions for reading cr3 and writing cr{3,4} are defined in tlbflush.h and system.h, whith just a name change. The only difference is the clobbering of memory, which seems a safe, and even needed change for the write_cr4. This patch removes the duplicate. write_cr3() is moved to system.h for consistency. Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com> -- Glauber de Oliveira Costa Red Hat Inc. "Free as in Freedom" -

On Tue, 13 Mar 2007 13:13:12 +0100 (CET) I have the pieces that fix all this, but not yet integrated into the main tree. With 2.6.21rc3 you have 80 wire cables you may find that simply hacking the driver to set ATA_CBL_PATA80 is sufficient, but maybe not. Alan -

Hi, I use kthread in my driver. The problem is that I can't kill process with kill_proc function. After rmmod my_driver, ps command shows again SW my_driver. How can I remove this process? Thank you -

There are problems in the use of SPARSEMEM and pageblock flags that causes problems on ia64. The first part of the problem is that units are incorrect in SECTION_BLOCKFLAGS_BITS computation. This results in a map_section's section_mem_map being treated as part of a bitmap which isn't good. This was evident with an invalid virtual address when mem_init attempted to free bootmem pages while relinquishing control from the bootmem allocator. The second part of the problem occurs because the ...

This last patch is an adaptation of the sys_futex64 syscall provided in -rt patch (originally written by Ingo). It allows the use of 64bit futex. I have re-worked most of the code to avoid the duplication of the code. It does not provide the functionality for all architectures (only for x64 for now). Signed-off-by: Pierre Peiffer <pierre.peiffer@bull.net> --- include/asm-x86_64/futex.h | 113 ++++++++++++++++++++ include/asm-x86_64/unistd.h | 4 include/linux/futex.h | 7 ...

Hi Robert, not only this piece of hardware, but many others - for example almost all Bluetooth keyboards and mice are capable of working both in HID and HCI modes, etc. The layer introduced in 2.6.20 gives them the possibility of I don't think so. Firstly, it will take some time until the HID layer is converted to bus, as I have another things pending. Secondly, the iowarrior driver will still be needed to handle the HW-specific reports that won't be handled by the generic HID layer, ...

Hi Andrew, This is a re-send of a series of patches concerning futexes (here after is a short description) Could you consider them for inclusion in -mm tree ? All of them have already been discussed in January and have already been included in -rt for a while. I think that we agreed to potentially include them in the -mm tree. Ulrich is specially interested by sys_futex64. There are: * futex uses prio list : allows RT-threads to be woken in priority order instead of FIFO ...

Thanks for your answer. Since this board has linuxbios support and i plan to put it on this board, there has been a post which tells the right boot parameters: apic=debug acpi_dbg_level=0xffffffff pci=noacpi,routeirq snd-hda-intel.enable_msi=1 I guess the "pci=noacpi,routeirq" makes the difference, but i haven't tried yet myself. ST -

The structure has been moved to include/media/v4l2-dev.h Best regards, Laurent Pinchart -

I'll do no such thing, and don't appreciate the insinuation. -Mike -

>>>>> "Serge" == Serge Belyshev <belyshev@depni.sinp.msu.ru> writes: Serge> Mike Galbraith <efault@gmx.de> writes: Serge> Whaa? make -j8 on mainline makes my desktop box completely Serge> useless. I tried a make -j5 on my Dual processor PIII Xeon box. It was pretty slow. Firefox was ok scrolling with keyboard, but the scrollbar was jerky. I also has MP3s playing at the same time and it worked just fine. No drops that I heard. This is 2.6.21-rc3 patched with RSDL. To me, that ...

My first test run with lame at nice 0 was truly horrid, but has _not_ repeated, so disregard that as an anomaly. For the most part, it is as you say, things just get slower with load, any load. I definitely am seeing lurchiness which is not present in mainline. No audio problems It seems to be a plain linear slowdown. The lurchiness I'm experiencing varies in intensity, and is impossible to quantify. I see neither Absolutely, all test results count. -Mike -

The OPEN_MAX macro in limits.h should not be there. It claims to be the limit on file descriptors in a process, but its value is wrong for that. There is no constant value, but a variable resource limit (RLIMIT_NOFILE). Nothing in the kernel uses OPEN_MAX except things that are wrong to do so. I've submitted other patches to remove those uses. The proper thing to do according to POSIX is not to define OPEN_MAX at all. The sysconf (_SC_OPEN_MAX) implementation works by calling ...

This is a bad idea. From linux/fs.h: #undef NR_OPEN #define NR_OPEN (1024*1024) /* Absolute upper limit on fd num */ There isn't anything I can see guaranteeing that net/scm.h is included before fs.h. This affects networking and should really be Cc'd to netdev@vger.kernel.org, which will raise the issue that if SCM_MAX_FD is raised, the resulting simple kmalloc() must be changed. That said, I doubt SCM_MAX_FD really needs to be raised, as applications using many file ...

Ok. My only agenda is to get rid of OPEN_MAX. I then propose the following instead. Thanks, Roland --- [PATCH] avoid OPEN_MAX in SCM_MAX_FD The OPEN_MAX constant is an arbitrary number with no useful relation to anything. Nothing should be using it. SCM_MAX_FD is just an arbitrary constant and it should be clear that its value is chosen in net/scm.h and not actually derived from anything else meaningful in the system. Signed-off-by: Roland McGrath <roland@redhat.com> --- ...

The CHILD_MAX macro in limits.h should not be there. It claims to be the limit on processes a user can own, but its value is wrong for that. There is no constant value, but a variable resource limit (RLIMIT_NPROC). Nothing in the kernel uses CHILD_MAX. The proper thing to do according to POSIX is not to define CHILD_MAX at all. The sysconf (_SC_CHILD_MAX) implementation works by calling getrlimit. Signed-off-by: Roland McGrath <roland@redhat.com> --- include/linux/limits.h | 1 - 1 ...

Greetings; Someone suggested a fresh thread for this. I now have my scripts more or less under control, and I can report that kernel-2.6.20.1 with no other patches does not exhibit the undesirable behaviour where tar thinks its all new, even when told to do a level 2 on a directory tree that hasn't been touched in months to update anything. Next up, 2.6.20.2, plain and with the latest RDSL-0.30 patch. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ...

Look at rootplug_init where it does mod_reg_security. If you have SELinux builtin, and subsequently register rootplug, it will stack under SELinux. Typically this Check the linux-security-module archives. This issue has been discussed quite extensively numerous times there. thanks, -chris -

Randy.Dunlap [rdunlap@xenotime.net] wrote: | On Mon, 12 Mar 2007 sukadev@us.ibm.com wrote: | | Please do a complete job on the 'for' line by eliminating the | space before each semi-colon. | | -- | ~Randy Ok. Here is the updated patch. The Patch 2/2 in this set should still apply cleanly on top of this. --- From: Sukadev Bhattiprolu <sukadev@us.ibm.com> Subject: [PATCH 1/2] Fix some coding-style errors in autofs Fix coding style errors (extra spaces, long lines) in autofs and ...

From: Sukadev Bhattiprolu <sukadev@us.ibm.com> Subject: [PATCH 1/5] statically initialize struct pid for swapper Statically initialize a struct pid for the swapper process (pid_t == 0) and attach it to init_task. This is needed so task_pid(), task_pgrp() and task_session() interfaces work on the swapper process also. Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> Cc: Cedric Le Goater <clg@fr.ibm.com> Cc: Dave Hansen <haveblue@us.ibm.com> Cc: Serge Hallyn <serue@us.ibm.com> Cc: ...

From: Sukadev Bhattiprolu <sukadev@us.ibm.com> Subject: [PATCH 4/5] Remove the likely(pid) check in copy_process Now that we pass in a struct pid parameter to copy_process() and even the swapper (pid_t == 0) has a valid struct pid, we no longer need this check. Changelog: Per Eric Biederman's comments, moved this out to a separate patch for easier review. Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> Cc: Cedric Le Goater <clg@fr.ibm.com> Cc: Dave Hansen ...

On Tue, Mar 13, 2007 at 10:22:53AM +0100, Rafael J. Wysocki wrote: > On Tuesday, 13 March 2007 05:08, Dave Jones wrote: > > I spent considerable time over the last day or so bisecting to > > find out why an X60 stopped resuming somewhen between 2.6.20 and current -git. > > (Total lockup, black screen of death). > > Do you have CONFIG_TICK_ONESHOT or CONFIG_NO_HZ set? If you do, could you > please unset them and retest? I did try with NO_HZ unset, made no difference, I don't recall ...

I spent considerable time over the last day or so bisecting to find out why an X60 stopped resuming somewhen between 2.6.20 and current -git. (Total lockup, black screen of death). The bisect log looked like this. git-bisect start # bad: [c8f71b01a50597e298dc3214a2f2be7b8d31170c] Linux 2.6.21-rc1 git-bisect bad c8f71b01a50597e298dc3214a2f2be7b8d31170c # good: [fa285a3d7924a0e3782926e51f16865c5129a2f7] Linux 2.6.20 git-bisect good fa285a3d7924a0e3782926e51f16865c5129a2f7 # bad: ...

From: Sukadev Bhattiprolu <sukadev@us.ibm.com> Subject: [PATCH 5/5] Use task_pgrp() task_session() in copy_process(). Use task_pgrp() and task_session() in copy_process(), and avoid find_pid() call when attaching the task to its process group and session. Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> Cc: Cedric Le Goater <clg@fr.ibm.com> Cc: Dave Hansen <haveblue@us.ibm.com> Cc: Serge Hallyn <serue@us.ibm.com> Cc: containers@lists.osdl.org Acked-by: Eric W. Biederman ...

SAT (aka ATA passthru) defines how to do soft-reset. SG_IO supports the ATA_12 and ATA_16 commands which permit soft-reset and similar tasks. libata supports this interface, but does not yet support soft-reset and similar non-comment-oriented tasks. This would be the best area to add such features, though. Jeff -

I have the same problem as yours. Do you have any idea to use ATI firegl driver in recent kernels ? Thanks in advance. Regards, albcamus -

Page allocator still requires interrupts to be disabled, which this doesn't. Considering there isn't much else that frees known zeroed pages, I wonder if it is worthwhile. Last time the zeroidle discussion came up was IIRC not actually real performance gain, just cooking the 1024 CPU threaded pagefault numbers ;) -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com -

Ok, then what did I do wrong 3 years ago with the prezeroing patchsets? -

Can pagetable pages be shared between mms? (Kernel pmds in PAE excepted.) J -

I'm trying to remember why we ever would have needed to zero out the pagetable pages if we're taking down the whole mm? Maybe it's because "oh, the arch wants to put this page into a quicklist to recycle it", which is all rather circular. It would be interesting to look at a) leave the page full of random garbage if we're releasing the whole mm and b) return it straight to the page allocator. -

Well we have the 'fullmm' case, which avoids all the locked pte operations (for those architectures where hardware pt walking requires atomicity). However we still have to visit those to-be-unmapped parts of the page table, to find the pages and free them. So we still at least need to bring it into cache for the read... at which point, the store probably isn't a big burden. -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com -

Because we'd need one link per mm that a page is mapped in? -- Mathematics is the supreme nostalgia of our time. -

On a Pentium 4? ;) Sure, that is a minor detail, considering that you'll usually be allocating The thing is, pagetable pages are the one really good exception to the rule that we should keep cache hot and initialise-on-demand. They typically are fairly sparsely populated and sparsely accessed. Even for last level page tables, I think it is reasonable to assume they will usually be pretty cold. And you want to allocate cache cold pages as well, for the same reasons (you want to keep your ...

Abstract quicklist from the OA64 implementation Extract the quicklist implementation for IA64, clean it up and generalize it to allow multiple quicklists and support for constructors and destructors.. Signed-off-by: Christoph Lameter <clameter@sgi.com> --- arch/ia64/Kconfig | 4 ++ arch/ia64/mm/contig.c | 2 - arch/ia64/mm/discontig.c | 2 - arch/ia64/mm/init.c | 51 --------------------------- include/asm-ia64/pgalloc.h | 82 ...

V1->V2 - Add sparch64 patch - Single i386 and x86_64 patch - Update attribution - Update justification - Update approvals - Earlier discussion of V1 was at http://marc.info/?l=linux-kernel&m=117357922219342&w=2 This patchset introduces an arch independent framework to handle lists of recently used page table pages. It is necessary for x86_64 and i386 to avoid the special casing of SLUB because these two platforms use fields in the page_struct (page->index and page->private) that SLUB ...

And do the same in pte pages for actual mapped pages? Or do you think they would be too densely populated for it to be worthwhile? J -

I suspect there are some tlb operations which could be skipped in that case It means all that data has to be written back. Yes, I expect it'll prove to be less costly than the initial load. -

Well if they're zero then perhaps they should be released to the page allocator to satisfy the next __GFP_ZERO request. If that request is for a pagetable page, we break even (except we get to remove special-case code). If that __GFP_ZERO allocation was or some application other than for a pagetable, we win. iow, can we just nuke 'em? (Will require some work in the page allocator) (That work will open the path to using the idle thread to prezero pages) -

I don't see much point to them. For powerpc, I would rather grab an My recollection was that it wasn't a win, but it was a long time ago... Paul. -

Nope that wont work. 1. We need to support other states of pages other than zeroed. 2. Prezeroing does not make much sense if a large portion of the page is being used. Performance is better if the whole page is zeroed directly before use.Prezeroing only makes sense for sparse I already tried that 3 years ago and there was *no* benefit for usual users of the a page allocator. The advantage exists only if a small portion of the page is used. F.e. For one cacheline there was a 4x ...

eh? I'd have thought that a pte page which has just gone through zap_pte_range() will very often have a _lot_ of hot cachelines, and that's a common case. Yeah, prezeroing in idle is probably pointless. But I'm not aware of anyone having tried it properly... -

GCC (4.1 at least) unrolls it anyway, but I can't believe this code was ever justifiable. (I've also submitted a patch which cleans up i386, which is even uglier). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> diff -r de5618b5e562 include/asm-x86_64/desc.h --- a/include/asm-x86_64/desc.h Tue Mar 13 11:41:55 2007 +1100 +++ b/include/asm-x86_64/desc.h Tue Mar 13 16:09:56 2007 +1100 @@ -135,16 +135,13 @@ static inline void set_ldt_desc(unsigned (info)->useable == 0 && \ ...

Does it matter either way in this case? J -

subscribe to the linux-arm-kernel list and ask the question there, you'll find more ARM people there. -- Ben (ben@fluff.org, http://www.fluff.org/) 'a smiley only costs 4 bytes' -

this should be fixed in 2.6.21-rc3, commit ed8ccee0918ad063a4741c0656fda783e02df627 Bart -

argh. Would we break more machines than we fix if we just revert that? -

From: Sukadev Bhattiprolu <sukadev@us.ibm.com> Subject: [PATCH] Kill unused sesssion and group values in rocket driver The process_session() and process_group() values are not really used by the driver. Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> Cc: Cedric Le Goater <clg@fr.ibm.com> Cc: Dave Hansen <haveblue@us.ibm.com> Cc: Serge Hallyn <serue@us.ibm.com> Cc: containers@lists.osdl.org Cc: Eric W. Biederman <ebiederm@xmission.com> --- drivers/char/rocket.c | 3 --- ...

Subject: Simplify smp_call_function*() by using common implementation smp_call_function and smp_call_function_single are almost complete duplicates of the same logic. This patch combines them by implementing them in terms of the more general smp_call_function_mask(). Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com> Cc: Stephane Eranian <eranian@hpl.hp.com> Cc: Andrew Morton <akpm@osdl.org> Cc: Andi Kleen <ak@suse.de> Cc: "Randy.Dunlap" <rdunlap@xenotime.net> Cc: Ingo Molnar ...

I don't think the patch should make any difference, so that's not needed. -Andi -

It's also useful documentation. Knowing whether a function is __init is an important part of its interface. J -

User build was smoking this: make O=build -j16 This and non-repeatable results make me suspect some kind of build dependency problem, or perhaps a make bug. Still, please apply, as it doesn't hurt. Zach -

Really truly? I think we have a _lot_ of declarations which omit the section qualifier altogether. How come they don't all break too? (ARM (at least) in fact does require the section tagging on the declaration as well as the definition, but we've thus far only fixed that in a couple of places which were causing breakage). -

Hi Mathieu, Hmm, djprobe already might not wait for each CPU to hit the probe point. It just wait scheduler synchronization instead of that. And after that, it issues cpuid for cache serialization before executing cross-modified code. The most difficult point of the djprobe is that it has to replace "live" instructions. So we must check other processors not to run Same idea was already discussed. It might work on normal kernel, but, unfortunately, it doesn't work on preemptive ...

Most Asus boards have jumpers for the USB ports to select between +5V and +5VSB (stand by power). The reason to provide standby power is so that keyboards with power buttons can remain powered so that you can turn the system on using the usb keyboard. If you want to power off the ports entirely, jumper them to the +5V line instead which only has power when the system is on. -- Len Sorensen -

It ought to be rock solid, perhaps you can send me a detailed bug report. In fact it actually doesn't do very much at all as the controller is The two drive the devices identically although if there was a problem I guess the libata one would recover better. Would appreciate bug reports anyway so I can do more detailed analysis. Alan -

Fair enough. It'd be nice to have a clean-up-a-patch version of this. So it does all these things, except it only changes lines which start with ^+. -

It can do everything except kill empty lines at the end of the file; a patch simply doesn't contain enough information to know if blank lines are inserted at the end of a file as opposed in the middle of the file. It can, of course, be done if the unpatched material is available, probably by applying the patch and seeing what happens. Let me know if you still want it; I'll whip it up. -hpa -

Regardless, of what you'll do: cross-compile test! After aforementioned removal and adding "struct kernel_param;" + akmk arm-assabet -k CHK include/linux/version.h make[2]: `include/asm-arm/mach-types.h' is up to date. Using /home/linux/linux-irq-flags-t as source for kernel GEN /home/linux/build/arm-assabet/Makefile CHK include/linux/utsrelease.h CHK include/linux/compile.h CC arch/arm/nwfpe/fpmodule.o arch/arm/nwfpe/fpmodule.c:179: error: syntax error ...

nope, no numbers for that, but I appreciate some testing and probably can do some testing in this regard too (although I want to get some testing done for the resource host only for now best, -

I think we should experiment with both combinations (a direct pointer to cpu_limit structure from task_struct and an indirect pointer), get some numbers and then decide. Or do you have results already with Interesting. What abt /dev/cpuset view? Is that same for all containers or do you restrict that view to the containers cpuset only? -- Regards, vatsa -

It's good to keep this type of information in drivers. I've been thinking lately that it would be nice to even expand it a little bit (maybe include the commit sum) so its easier to help those who aren't running the latest upstream kernels on their boxes.... -

The patch is for 2.6.21-rc3, sorry for not making it clear. Bart -

Michael, please stop spreading this utter bullshit _now_. You're so full of half-knowledge that it's not funny anymore, and you try to insult people knowing a few magniutes more than you left and right. Can you please select a different mailinglist for your trolling? -

OK, I laughed out loud at this. But I think you're missing my point, which is that there's a time to be hard-core about code quality and there's a time to be hard-core about _product_ quality. Face it, all products containing software more or less suck. This is because most programmers write crap code most of the time. The only way to cope with this, outside the confines of the European defense industry and other niches insulated from economic reality, is to make the production environment ...

Clearly f_pos atomicity has been handled differently in the not-so-distant past: http://www.mail-archive.com/linux-fsdevel@vger.kernel.org/msg01628.html And equally clearly the current generic_file_llseek semantics are erroneous for large offsets, and we shouldn't be taking the inode mutex in any case other than SEEK_END: http://marc.theaimsgroup.com/?l=linux-fsdevel&m=100584441922835&w=2 read_write.c is a perfect example of the relative amateurishness of parts of the Linux kernel. It ...

pread/pwrite address a miniscule fraction of lseek+read(v)/write(v) use cases -- a fraction that someone cared about strongly enough to get into X/Open CAE Spec Issue 5 Version 2 (1997), from which it propagated into UNIX98 and thence into POSIX.2 2001. The fact that no one has bothered to implement preadv/pwritev in the decade since pread/pwrite entered the Single UNIX standard reflects the rarity with which they appear in general code. Life is too short to spend it rewriting application ...

One way to do this is to use kprobes which will do exactly what you want Not easily with gdbstubs as you've got to talk to something to decide how to log the data and proceed. If you stick it kernel side its a lot of ugly new code and easier to port kprobes over, if you do it remotely as gdbstubs intends it adds latencies and screws all your timings. gdbstubs is also not terribly SMP aware and for low level work its sometimes easier to have on gdb per processor if you can get your ...

Very nice. Thanks for the feedback and I'm sorry you have to work with such lousy hardware. -- -ck -

Sounds like Wengophone is broken. It should be using RT threads for time critical work, as JACK and Ardour2 are doing. No scheduler can help if the apps are not correctly written... Lee -

Considering that Con's general mass target for his -ck patchset is single-cored x86/PC-compatable system such as a Celeron or a single-core Athlon with 32-256 MB RAM, (disclaimer: this is an assumption) I think he is being rather sarcastic. The only other way to interpret this is that those machines are totally different from what Con uses for development, and as such, maybe Con'd find them "lousy" because if something DID go wrong, it would be less obvious he'd figure it out right away. But I ...

Well this was supposed to be solved by RLIMIT_NICE and RLIMIT_RTPRIO which went into mainline about a year ago but distros have been very slow to pick up the new PAM, glibc and bash packages. We don't have a clear picture yet of what defaults the distros will ship. Lee -

Well the change to -nice values was to minimise the harm they do to everything else. They will still get the lowest latencies and the most cpu but no more than previously. The difference will be to more niced tasks. I'm not sure just how much cpu you require for wengophone because at -5 it would be getting a fair chunk of cpu with the RSDL 0.30. Anyway, by sheer coincidence I just emailed out that patch I was planning so feel free to try it. -- -ck -

I was referring to arch/ppc not arch/powerpc. But it seems that arch/ppc doesn't support cpu hotplug anyway. So I guess it's indeed just a missing config option. Grepping a bit further shows that arm suffered by the change that inverted the logic if the 'online' attribute for cpus should appear. Since arm supports cpu hotplug but the patch left arm out, it doesn't work there anymore (cc'ing arm people: changeset 72486f1f8f0a2bc828b9d30cf4690cf2dd6807fc is most probably disabling cpu hotplug ...

I think if there is no hotplug support then the file should not be created in the first place. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -

Should have cc'ed Suresh Siddha who caused the breakage ;) -

There's a distinction between giving it more cpu and giving it higher priority: the important part about having high priority is getting low This really seems like the wrong approach to me. The implication here and in other mails is that fairness is an inherently good thing which should obviously take preference over any other property. It's a nice simple stance, and its relatively easy to code up and test to see that its working, but it doesn't really give people what they want. The old ...

And again, with X in its current implementation it is NOT like two nice 0 tasks at all; it is like one nice 0 task. This is being fixed in the X design -- -ck -

Hm, well. The general preference has been for the kernel to do a good-enough job on getting the common cases right without tuning, and then only add knobs for the really tricky cases it can't do well. But the impression I'm getting here is that you often get sucky behaviours Well, it doesn't have to. It could give good low latency with short timeslices to things which appear to be interactive. If the interactive program doesn't make good use of its low latency, then it will suck. For ...

Hello Ingo, After talking to Con over IRC (and if I can summarize it), he's wondering if properly nicing those tasks, as previously mention in user emails, would solve this potential user reported regression or is something additional needed. It seems like folks are happy with the results once the nice tweeking is done. This is a huge behavior change after all to scheduler (just thinking out loud). bill -

I don't know what else you can do when the argument is that behavior that is wrong is what you actually want. The regression is not that the scheduler doesn't do what it was asked to do or even that it isn't more faithful to what it was told to do than the scheduler it replaces. The regression is that the scheduler didn't do what Mike wanted it to do, even though he didn't ask it to do that. I would argue this is progression, not regression. The new scheduler is fairer than the old one and ...

Yet looking at the mainline scheduler code, nice 5 tasks are also supposed to get 75% cpu compared to nice 0 tasks, however I cannot seem to get 75% cpu with a fully cpu bound task in the presence of an interactive task. To me that means mainline is not living up to my expectations. What you're saying is your expectations are based on a false cpu expectation from nice 5. You can spin it both ways. It seems to me the only one that lives up to a defined expectation is to be fair. Anything ...

i think Mike's testcase was even simpler than that: two plain CPU hogs on nice +5 stole much more CPU time with Con's new interactivity code than they did with the current interactivity code. I'd agree with Mike that a phenomenon like that needs to be fixed. /less/ interactivity we can do easily in the current scheduler: just remove various bits here and there. The RSDL promise is that it gives us /more/ interactivity (with 'interactivity designed in', etc.), which in yeah. It's a ...

Also, just to chime in, I am doing a large project converting over 250GB of FLAC audio to MP3 via lame for my archive conversion. I am using 2.6.20.2-rsdl0.30, and I have 2 processes of flac decoding/lame encoding running simultaneously from a perl script I hacked up on my P-D 830. These processes are both nice'd to 19. I have almost no degredation in latency in my usage of X (which is at nice 0), if that matters at all. Please try what Con is suggesting by adjusting your nice level, ...

Sure. If a user wants to do anything interactive, they can indeed nice It's not "offensive" to me, it is a behavioral regression. The situation as we speak is that you can run cpu intensive tasks while watching eye-candy. With RSDL, you can't, you feel the non-interactive load instantly. Doesn't the fact that you're asking me to lower my I'm not trying to be pig-headed. I'm of the opinion that fairness is great... until you strictly enforce it wrt interactive tasks. -Mike -

I just retested with the encoders at nice 0, and the x/gforce combo is terrible. Funny thing though, x/gforce isn't as badly affected with a kernel build. Any build is quite noticable, but even at -j8, the effect doen't seem to be (very brief test warning applies) as bad as with only the two encoders running. That seems quite odd. -Mike -

Is gforce calling sched_yield? Can you try testing with some simpler loads, like these: memload: #!/usr/bin/python a = "a" * 16 * 1024 * 1024 while 1: b = a[1:] + "b" a = b[1:] + "c" execload: #!/bin/sh exec ./execload forkload: #!/bin/sh ./forkload& pipeload: #!/usr/bin/python import os pi, po = os.pipe() if os.fork(): while 1: os.write(po, "A" * 4096) else: while 1: os.read(pi, 4096) -- Mathematics is the supreme nostalgia of our time. -

tcsh, and probably csh, has a builtin 'nice' with default +4. So tcsh% nice ps -l will show a process with nice +4. If you tell it not to use the builtin, tcsh% \nice ps -l then it uses /usr/bin/nice and you get +10. bash doesn't have a nice builtin, so it always uses /usr/bin/nice and you get +10 by default. -Sanjoy `Not all those who wander are lost.' (J.R.R. Tolkien) -

Maybe extend UNIX sockets to add another passable object type vis-a- vis SCM_RIGHTS, except in this case "SCM_CPUTIME". You call SCM_CPUTIME with a time value in monotonic real-time nanoseconds (duration) and a value out of 100 indicating what percentage of your timeslices to give to the process (for the specified duration). The receiving process would be informed of the estimated total number of nanoseconds of timeslice that it will be given based on the priority of the ...

I'm not an expert in this area by any means but after reading this thread the OSX solution of simply telling the kernel "I'm the GUI, schedule me accordingly" looks increasingly attractive. Why make the kernel guess when we can just be explicit? Does anyone know of a UNIX-like system that has managed to solve this problem without hooking the GUI into the scheduler? Lee -

(One more comment before I go. You can then have the last word this time, promise :) Because the interactivity logic, which was put there to do precisely Talk about spin, you turn an example of the current scheduler working properly into a negative attribute, and attempt to discredit me with it. The floor is yours. No reply will be forthcoming. -Mike -

i'm sorry, but your argument seems to be negated. We of course have no problem with interactive tasks stealing CPU time from CPU hogs. The situation Mike found is _the other direction_: that /CPU hogs/ stole from interactive tasks. That's bad and needs to be fixed. Please? Ingo -

From: David Miller <davem@davemloft.net> I want to quantify this with the fact that all the cache false sharing issues are irrelevant in this test because the L2 cache is shared between all of the cpu threads on Niagara. It was fast just because the quicklists were lighter weight than the SLAB stuff. -

From: Paul Mackerras <paulus@samba.org> It shaved about 3 or 4 seconds consistently off of my kernel build on Niagara which usually clocks in just over 4 minutes He just wants to side-step the issue in SLUB, which arguably is an attempt to simplify SLUB at the expense of functionality. I don't agree with that, but I'm merely preemptively testing his patches and porting them to sparc64 so it does not break when/if his code is merged in. After being bitten by stuff like this in the ...

Yes there a risk of wrapping, but it is very small. You can add the command line arguments to the file name if you want, like this : #!/bin/sh exec strace -f -o "output.$$.${*//\//_}" /bin/real.tar $@ It will name the output file "output.<pid>.<args>", replacing slashes with underscores. This is very dirty but can help. Cheers, Willy -

-- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Whatever doesn't succeed in two months and a half in California will never succeed. -- Rev. Henry Durant, founder of the University of California -

-- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com -

Well, that works. Andrew, I'm going to post an updated patch in separate email. Ralf -

Sorry, I must have messed up something. I've fixed up the original patch, this one should apply on top of the stable queue with the broken patch removed.

I don't think you'll get more feedback now. Just write the patch, benchmark it with your workload and also some others (basically, there should be no difference) and then submit the patch together with the performance numbers and some rationale (if it's your first submission, see Documentation/SubmittingPatches). Give also CC to Andrew <akpm@linux-foundation.org> and ask him to put it into -mm kernels for testing. Honza -- Jan Kara <jack@suse.cz> SuSE CR Labs -

I am getting the exact same line on bootup on my Fujitsu Siemens Lifebook E8110. After that line the boot halts with current git: Last lines on current git were: IPMI System Interface driver Clocksource tsc unstable ( delta =3D -160251929ns ) Now running: Linux laptop 2.6.21-rc2 #1 SMP PREEMPT Thu Mar 1 07:41:52 CET 2007 i686 GN= U/Linux which comes up with the same line when initializing IDE but continues to run: [ 9.912917] ICH7: IDE controller at PCI slot 0000:00:1f.1 [ ...

Good stuff. I suggest you put a big printk explaining the above into 2.6.21. -

Retesting today with 2.6.21-rc3-git7 + 2.6.21-rc3-sched-rsdl-0.30.patch. Still not pleasant to use the GUI with a kernel build (-j1 or -j2) happening unless the build is manually "nice'd". Also, accounting looks weird in top(1). Mmm.. I wonder where all of that 100% CPU went to.. the busiest tasks are only showing up as 4.0% and 1.7% (when in fact they are using near 100%). Cheers -

I considered that solution as well, and thought that it would then prevent the hasbin locks from being ever validated by lockdep. OTOH, the hashbin code is not likely to change anytime soon and is currently validated. Also, you will eventually push this code upstream, so I'd rather go for that fix ;-) Thanks for the comment. Cheers, Samuel. -

Hi Martin, sorry for joining so late. Most of your anxieties are unfounded: the pages your driver allocates with __get_free_pages are not put on any LRU (until they're freed), kernel pages are never swapped out, and making them visible to user- space does not put them in any more danger of being swapped out; but yes, if the refcounting goes wrong, that will cause premature freeing, "Bad page" messages, trouble. (Of course, filesystem pagecache pages are liable to be swapped out, and ...

Yep, it works fine with your patch in and my silly reverted, thanks. But (I was about to say, even before seeing Cornelia's reply, honest!) I think you do need to check (audit the source? or is some runtime check possible?) for other such "suicidal" sysfs files, which seemed to (sysfs-ignorant) me to pose the real problem. Hugh -

Indeed, and faint-hearted Hugh wasn't intending to do so: but stout-hearted Alan will need to, won't he, before his patch can go in? -

Hugh, there has been a long discussion among several people concerning this issue. See for example this thread: http://marc.info/?t=117335935200001&r=1&w=2 and also: http://marc.info/?l=linux-kernel&m=117355959020831&w=2 The consensus is that we would be better off keeping Oliver's original patch without your silly change, and instead fixing the particular method call that deadlocked. Can you please try out the patch below with everything else as it was before? It should solve ...

Allow me to point out that the original patch is Oliver's (although I helped), and it doesn't need to go in -- it needs not to be removed. Furthermore, I have better things to do with the next month of my time than auditing hundreds of routines I don't understand for behavior I probably won't be able to recognize. (Although at 50 a day... hmmm, maybe.) This sounds more like a job for kernel-janitors! Very good points. USB doesn't do anything like that either. And right, it's ...

There is a fundamental problem with using __thread, which is that gcc assumes that the addresses of __thread variables are constant within one thread, and that therefore it can cache the result of address calculations. However, with preempt, threads in the kernel can't rely on staying on one cpu, and therefore the addresses of per-cpu variables can change. There appears to be no way to tell gcc to drop all cached __thread variable address calculations at a given point (e.g. when enabling or ...

No, I don't think I will. The PDA concept has gone too far in x86-64 to be undone. In particular, it's been put in GCC 4.1 for CONFIG_CC_STACKPROTECTOR, which assumes %gs:40 will give the stack canary. For the record: the PDA should never have existed, that's what percpu vars were supposed to be for. Something went wrong here 8( %gs is best set to the offset of the local cpu's area from the "master" per-cpu area, not set to the local cpu area's address. In the former case, booting with ...

Then swapgs wouldn't work anymore (there is no swapfs) -

Hi, It looks like you might need: for (i--; i >= 0; i--) (or: for (j = 0; j < i; j++) etc.) Because if the initial alloc_page loop goes to completion then: i == pagecount and if alloc_page loop terminates early then bp->b_pages[i] == NULL So we have gone 1 too far in both cases and need to start free'ing back one. Unless I missed something. --Tim -

Ahha, now I see where the confusion comes from. No, the reader is not a serial device, it is reader build-in x60. USB serial device (siemens sx1) has separate problem. Device is 15:00.2 Generic system peripheral [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 18) root@amd:~# ls -al /dev/mmc brw-r--r-- 1 root root 251, 0 Nov 5 16:57 /dev/mmc ... ...anything else I should try? Card is obviously detected, but I can't access it.. Uhuh. User error, lets close the ...

Oops I missed that. Eric -

First I heard of this. The error report is a bit thin so Pavel will need to elaborate a bit more. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainer http://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org -

Indeed I would. -- -- Pierre Ossman Linux kernel, MMC maintainer http://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org -

Those whose Linux installation predates the devfs hype and postdates the devfs hype and predates the udev hype and will postdate the udev hype and predates the next hype cu Adri "static /dev" an -- "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 -

Here is a quick summary of the regressions I am looking at. - Currently we appear to have a pid leak in tty_io.c http://lkml.org/lkml/2007/3/8/222 - There is a missing init_WORK in vt.c that cases oops when we attempt to use SAK. http://lkml.org/lkml/2007/3/11/148 - We have a network ABI regression caused by the latest sysfs changes to net-sysfs.c In particular we now cannot rename network devices if our destination name happens to be the name of a sysfs file that the ...

The device is a USB serial device. USB serial was known to have issues in the version this happened. As far as I know the bug has not been replicated after this bugs were fixed. Regards Oliver -

I do not think this should be reverted, as the odds that some one will rename their network device to be "irq" or something else that is in the pci device's directory is pretty slim. It also only shows up if CONFIG_SYSFS_DEPRECATED is disabled, not the common option. But I am still working on it, I sent you and Kay a patch that, while it I think these are already in Linus's tree right now, right? thanks, greg k-h -

This email lists some known regressions in Linus' tree compared to 2.6.20. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject : ThinkPad X60: resume no longer works (PCI related?) References : ...

Pavel? Could you retest this now on a ThinkPad X60 ? ??? -

Yes. I just wanted some more testing of it, and while I didn't hear much, at least Auke added his ack, and the old state was clearly broken, so they got applied yesterday. Linus -

This email lists some known regressions in Linus' tree compared to 2.6.20. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject : crashes in KDE References : ...

It uses RDTSC when it shouldn't. Already got a fix for that. -Andi -

At Tue, 13 Mar 2007 13:49:57 +0100, Already fixed. The patch is in ALSA HG tree, but not synced to git... Jaroslav, could you do prepare and push request ASAP, please? thanks, Takashi -

Some cases should be fixed now but probably not all (eg the Nvidia one) -

What this loop is doing is putting write requests in the request queue, and in so doing transforming page state from dirty to Because the lower filesystem writes back one request, but then gets stuck in balance_dirty_pages before returning. So the write request is never completed. The problem is that balance_dirty_pages is waiting for the condition that the global number of dirty+writeback pages goes below the threshold. But this condition can only be satisfied if This is the fuse ...

I have a problem doing a group-reply in mutt to Herbert's mails. His email id gets dropped from the To or Cc list. Is that his email setting? Don't know. -- Regards, vatsa -

My first worry was that this approach is unfair to the poor bastard that happened to get started up first. If we have a bunch of containerized web servers, the poor guy who starts Apache first will pay the price for keeping it in memory for everybody else. That said, I think this is naturally worked around. The guy charged unfairly will get reclaim started on himself sooner. This will tend to page out those pages that he was being unfairly charged for. Hopefully, they will eventually get ...

my mail client is not involved in receiving the emails, so the email I replied to did already miss you in the cc (i.e. I doubt that mutt would hide you from the cc, if it would be present in the mailbox :) maybe one of the mailing lists is removing receipients according to some strange scheme? here are the full headers for the email I replied to: -8<------------------------------------------------------------------------

Is the page stays mapped for the container or not? If yes then what's the use of limits? Container mapped pages more than the limit is but all the pages are -

I was just reading through the (comprehensive) thread about this from last week, so forgive me if I missed some of it. The idea is really tempting, precisely because I don't think anyone really wants to have to screw with the reclaim logic. I'm just brain-dumping here, hoping that somebody has already thought through some of this stuff. It's not a bitch-fest, I promise. :) How do we determine what is shared, and goes into the shared zones? Once we've allocated a page, it's too late ...

sounds weird, but makes sense if you look at the full picture just because the guest is over its page limit doesn't mean that you actually want the system to swap stuff out, what you really want to happen is the following: - somehow mark those pages as 'gone' for the guest - penalize the guest (and only the guest) for the 'virtual' swap/page operation - penalize the guest again for paging in the page - drop/swap/page out those pages when the host system you tell me? or is that ...

I'm talking not about the finess of the code, but rather about the lack of isolation, i.e. one VE can affect others. Kirill -

I think as far as having this discussion if you can remove that race people will be more willing to talk about what vserver does. That said anything that uses locks or atomic operations (finer grained locks) because of the cache line ping pong is going to have scaling issues on large boxes. So in that sense anything short of per cpu variables sucks at scale. That said I would much rather get a simple correct version without the complexity of per cpu counters, before we optimize the ...

Let's be practical here, what you're asking is basically impossible. Unless by deterministic you mean that it never enters the a non trivial syscall, in which case, you just want to know about maximum It is basically handwaving anyway. The only approach I've seen with a sane (not perfect, but good) way of accounting memory use is this one. If you care to define "proper", then we could discuss that. -- SUSE Labs, Novell Inc. Send instant messages to your online friends ...

I will tell you what I want. I want a shared page cache that has nothing to do with RSS limits. I want an RSS limit that once I know I can run a deterministic application with a fixed set of inputs in I want to know it will always run. First touch page ownership does not guarantee give me anything useful for knowing if I can run my application or not. Because of page sharing my application might run inside the rss limit only because I got lucky and happened to share a lot of pages with ...

"Is it useful for me as a bad guy to make it happen ?" Alan -

I would be happy to propose OVZ approach then, where a page is tracked with page_beancounter data structure, which ties together a page with beancounters which use it like this: page -> page_beancounter -> list of beanocunters which has the page mapped This gives a number of advantages: - the page is accounted to all the VEs which actually use it. - allows almost accurate tracking of page fractions used by VEs depending on how many VEs mapped the page. - allows to track dirty pages, i.e. ...

No the fact that a page mapped into 2 separate mm_structs in two separate accounting domains is counted only once. This is very likely to happen with things like glibc if you have a read-only shared copy of your distro. There appears to be no technical reason for such a restriction. A page should not be owned. Going further unless the limits are draconian I don't expect users to hit the rss limits often or frequently. So in 99% of all cases page reclaim should continue to be global. ...

BTW atomic_add_unless() is essentially a loop!!! Just like spin_lock() is, so why is one better that another? spin_lock() can go to schedule() on preemptive kernels -

Which is a questionable assumption. Worse case we are talking a list several thousand entries long, and generally if you are used by the same container you will hit one of your processes long before you traverse the whole list. So at least the average case performance should be good. It is only in the case when you a page is shared between multiple containers when this matters. Eric -

Why testing with qemu is not enough. diff -r 8dcd1dc9b298 arch/i386/kernel/cpu/common.c --- a/arch/i386/kernel/cpu/common.c Tue Mar 13 00:33:37 2007 -0700 +++ b/arch/i386/kernel/cpu/common.c Tue Mar 13 08:33:42 2007 -0700 @@ -627,7 +627,7 @@ __cpuinit void init_gdt(int cpu, struct pack_descriptor((u32 *)&gdt[GDT_ENTRY_PERCPU].a, (u32 *)&gdt[GDT_ENTRY_PERCPU].b, __per_cpu_offset[cpu], 0xFFFFF, - 0x80 | DESCTYPE_S | 0x2, 0); /* present read-write data segment */ + 0x80 | ...

From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> Applied, thanks Geert. -

This patch adds all the "tm_new" laptops information that is in acerhk to wistron_btns. That's about 25 more laptops. Obviously, I couldn't try them all. I've just tried the Aspire 3020. For this reason, I've also added a printk which ask the users of those laptops to confirm me it works (or not). Surprisingly, the dmi information could be found on google for a majority of the laptops, so it might not work so badly. The information about which laptop has which led is also imported, ...

The rsdl patches queued up so far are stable and boot fine and are reasonably performant on many architectures so I'm quite happy for them to get a run in -mm. The changes planned will (as you may have seen on this email thread) decrease average latencies across all nice levels, and make differential nice levels run better together. This will allow -nice to be used without significant latency harm to not niced tasks (as there is presently in rsdl and mainline). The change required on top ...

Can you try the attached patch please Al and Mike? It "dithers" the priority bitmap which tends to fluctuate the latency a lot more but in a cyclical fashion. This tends to make the max latency bound to a smaller value and should make it possible to run -nice tasks without killing the latency of the non niced tasks. Eg you could possibly run X nice -10 at a guess like we used to in 2.4 days. It's not essential of course, but is a workaround for Mike's testcase. Thanks. --- Modify the ...

Oops, one tiny fix. This is a respin of the patch, sorry. --- Modify the priority bitmaps of different nice levels to be dithered minimising the latency likely when different nice levels are used. This allows low cpu using relatively niced tasks to still get low latency in the presence of less niced tasks. Fix the accounting on -nice levels to not be scaled by HZ. Signed-off-by: Con Kolivas <kernel@kolivas.org> --- kernel/sched.c | 73 ...

2.6.21-rc3-git with platform (previous method was reboot) method works OK. -- Lukáš Hejtmánek -

There weren't any changes neither in HW config nor in modules, just reverted, compiled, installed, rebooted. Mouse is HID user too, so I So, do you mean rmmod uhci_hcd, unplug the keyboard, modprobe uhci_hcd, start usbmon, plug the keyboard, press numlock, stop usbmon, post it? I'm away from the box till Sat, anyway. regards, -- http://www.fi.muni.cz/~xslaby/ Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey ...

Well, its a matter of degree. If your busy vcpu is sharing a real cpu with 9 other busy vcpus, then you'll only see about 10% of the real cpu cycles. If we had legitimate loads in which 90% of the cpu were taken up by interrupt processing, then I think we definitely would try to account for that time properly. SMM interrupts, in which the CPU is stolen from the kernel entirely, is a better analogy. But again, they're expected to be rare and insignificant. In a virtual machine, on the ...

But that is just what a interrupt is. -Andi -

I think it's better to remove this completely and not allow paravirt to hook into sched_clock. After all a hypervisor stealing time is no different from interrupts stealing time and we don't try to handle that either. I will remove the custom hook. -Andi -

Well, in that case you probably don't want to charge them to the process which happens to be running at the time. J -

you know better than I that stable branch doesn't differ much, especially in securiy (because it lacks these controls at all). BTW, killing arbitrary task in case of RSS limit hit It's a pity, but it took me only 5 minutes of looking into the code, Forget about Vserver and OpenVZ. It is not a war. We are looking for something working, new and robust. I'm just trying you to show that non-intrusive and pretty small accounting/limiting code like in Vserver simply doesn't work. The problem of ...

first, fix your mail client to get the quoting right, it is quite unreadable the way it is (not the first see how readable and easily understandable the code is? it takes me several hours to read OpenVZ code, and that's simply doesn't work? because you didn't try to make it work? as we are discussing RSS limits, there are actually three different (existing) approaches we have talked about: - 'the 'perfect RAM counter' each page is accounted exactly once, when used in a ...

That's assuming that you're using network namespace virtualization, with each group of tasks in a separate namespace. What if you don't want the virtualization overhead, just the accounting? Paul -

Considering the example Sam quoted, doesn't it make sense to split resource classes (some of them atleast) independent of each other? That would also argue for providing multiple hierarchy feature in Paul's patches. Given that and the mail Serge sent on why nsproxy optimization is usefull given numbers, can you reconsider your earlier proposals as below: - pid_ns and resource parameters should be in a single struct (point 1c, 7b in [1]) - pointers to resource controlling objects ...

No, any open port has taken a reference in serial_open(): serial = usb_serial_get_by_index(tty->index); destroy_serial() can be called only when the refcount goes to zero. How can there be open ports? Regards Oliver -

While we are at it, is there a reason we call return_serial() late in the sequence? Making sure the device is not reopened should be the first measure. Are we protected by hanging up the tty? Secondly, what is this code supposed to do: for (i = 0; i < serial->num_ports; ++i) serial->port[i]->open_count = 0; If we get to destroy_serial(), how can ports still be open? Regards Oliver -

Okay, so.. Jim, could you spell it out for us now? I'm confused. Based on the current 2.6.21-rc3-git*, tell us *exactly* what (if any) needs to be reverted, and *exactly* which (if any) of my suggested patches to apply ? Thanks -

Hi, libata.noacpi=1 worked. The drive is up and running with NCQ on. Here is the PATA/SATA related part of my DSDT table with the _GTF methods: Device (PATA) { Name (_ADR, 0x001F0001) OperationRegion (PACS, PCI_Config, 0x40, 0xC0) Field (PACS, DWordAcc, NoLock, Preserve) { PRIT, 16, Offset (0x04), PSIT, 4, Offset (0x08), SYNC, 4, Offset (0x0A), SDT0, 2, , 2, SDT1, 2, ...

Not as far as I can see. The serial structure that ->port[i] is in gets kfree()ed soon after, in the same function, and nothing in between, other than ->shutdown(), uses ->port[]. I assume it was someone being overly cautious. -Jim -

Patch applied, tested, works for me. Signed-Off: Jim Radford <radford@blackbean.org> Acked-by: Mark Lord <mlord@pobox.com> --- b/drivers/usb/serial/usb-serial.c +++ a/drivers/usb/serial/usb-serial.c @@ -137,6 +135,11 @@ dbg("%s - %s", __FUNCTION__, serial->type->description); + serial->type->shutdown(serial); + + /* return the minor range that this device had */ + return_serial(serial); + for (i = 0; i < serial->num_ports; ++i) serial->port[i]->open_count = 0; @@ ...

This neednt guarantee that the thread will see the stop request before it exits the kthread_should_stop_freeze() function. There will always be races .. So the only safe way for a thread to know whether it is time to exit is: while (!kthread_should_stop_freeze()) { if (!cpu_online(home_cpu)) goto wait_to_die; ... } wait_to_die: while (!kthread_should_stop()) { /* sleep */ } -- Regards, vatsa -

Well, it takes a lot of time to convert all the existing users. But I try to make sure to flame^H^H^H^H^Hcorrect everyone who tries to sneak a new user of kernel_thread in. -

Another problem is people doing "kthread_should_stop()" and forgetting about freezing. Then we continue ending up with situations where we are intermittently unable to freeze. In the spirit of "Rusty Scale" interface design, how do we make it difficult for people to misuse this interface? Thanx, Paul -

Have you tried, instead, to apply 38f3323037de22bb0089d08be27be01196e7148b ? (That is revert 39d61db0edb34d60b83c5e0d62d0e906578cc707). I suspect this is the proper fix... -

When you said idle I thought idle and not waiting for I/O. Waiting for I/O would be hardly a kernel issue ;). If they're not waiting for I/O and they're not scheduling in userland with nanosleep/pause, the cpu shouldn't go idle. Even if they're calling sched_yield in a loop the cpu should account for zero idle time as far as I can tell. -

The initial assumption was that there was zero idle time with threads = cpus and the idle time showed up only when the number of threads increased to the double the number of cpus. If the idle time wouldn't It'd be interesting to see the sysrq+t after the idle time My wild guess is that they're allocating memory after taking futexes. If they do, something like this will happen: taskA taskB taskC user lock mmap_sem lock mmap sem -> schedule user lock -> ...

Well it wasn't iowait time. From Anton's analysis, I would probably say it was time waiting for either the glibc malloc mutex or MySQL heap mutex. -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com -

I cooked a patch some time ago to speedup threaded apps and got no feedback. http://lkml.org/lkml/2006/8/9/26 Maybe we have to wait for 32 core cpu before thinking of cache line bouncings... -

btw, regardless of what glibc is doing, still the cpu shouldn't go idle IMHO. Even if we're overscheduling and trashing over the mmap_sem with threads (no idea if other OS schedules the task away when they find the other cpu in the mmap critical section), or if we've overscheduling with futex locking, the cpu usage should remain 100% system time in the worst case. The only explanation for going idle legitimately could be on HT cpus where HT may hurt more than help but on real multicore it ...

Well ignoring the HT issue, I was seeing lots of idle time simply because userspace could not keep up enough load to the scheduler. There simply were fewer runnable tasks than CPU cores. But it wasn't a case of all CPUs going idle, just most of them ;) -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com -

Well I think more threads ~= more probability that this guy is going to be preempted while holding the mutex? This might be why FreeBSD works much better, because it looks like MySQL actually will set RT scheduling for those processes that take critical I would agree that it points to MySQL scalability issues, however the fact that such large gains come from tcmalloc is still interesting. -- SUSE Labs, Novell Inc. Send instant messages to your online friends ...

Hi Stephen, Well, I have cleaned it a little bit, there were more comments and ifdefs than code ! I've appended it to the end of this mail. I have changed it a bit, because I noticed that integer divide precision was so coarse that there were other possibilities to play with the bits. I have experimented with combinations of several methods : - replace integer divides with multiplies/shifts where possible. - compensation for divide imprecisions by adding/removing small values ...

I have tried out 3.0.0-rc2 which seems to work pretty well so far (when combined with the patches to the jsm driver I just posted). It took soe work to get ntp's refclock_nmea to work though, since the patch that is linked to from the linuxpps page seems out of date. Here is the patch that seems to be working for me, although I am still testing it. Given you know the linuxpps code better perhaps you can see if it looks sane to you. --- ntpd/refclock_nmea.c.ori 2007-03-13 18:38:01.000000000 ...

I'd like to have the drivers and filesystems need to know as little as possible about whether they're working in MMU-mode or NOMMU-mode - for the most part such knowledge should be unnecessary. Additionally, I'd rather not put special case code in the generic parts of the NOMMU code. David -

Yes, the code could be reworked by moving some of the data from the CPU hw-breakpoint info into the thread's info. I'll see how much simpler it It isn't quite that easy. Even though the number of user breakpoints may not have changed, their identities may have. So the unlikely case has to encompass two possibilities: the number of installable user breakpoints This shouldn't be necessary. So long as DR_GLOBAL_ENABLE always belongs to the kernel's part of DR7 and DR_LOCAL_ENABLE always ...

By modifying scripts/pnmtologo.c to add `const' to the declaration of the linux_logo structs, I could keep the const. However, this introduced a new conflict w.r.t. to `const' and `__initdata': - gcc 3.4.6 20060404 (Red Hat 3.4.6-3) for ia32 needs xxx_data[] and xxx_clut[] to be const too, else it complains about a section type conflict - ppu-gcc 4.1.0 20060304 (Red Hat 4.1.0-3) for ppc64 needs xxx_data[] and xxx_clut[] to be non-const, else it complains about a section type ...