Re: slab allocators: Remove obsolete SLAB_MUST_HWCACHE_ALIGN

2007-04-17 Thread Pekka Enberg
there reflects some earlier role that the slab flag once may have had. If its specified then SLAB_HWCACHE_ALIGN is also specified. The flag is confusing, inconsistent and has no purpose. Remove it. Acked-by: Pekka Enberg [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux

Re: [PATCH] Show slab memory usage on OOM and SysRq-M

2007-04-17 Thread Pekka Enberg
Hi, On 4/17/07, Pavel Emelianov [EMAIL PROTECTED] wrote: The out_of_memory() function and SysRq-M handler call show_mem() to show the current memory usage state. This is also helpful to see which slabs are the largest in the system. Makes sense. On 4/17/07, Pavel Emelianov [EMAIL PROTECTED]

Re: [PATCH] Show slab memory usage on OOM and SysRq-M (v2)

2007-04-18 Thread Pekka Enberg
. Acked-by: Pekka Enberg [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH 2/7] revoke: add f_light flag for struct file

2007-03-09 Thread Pekka Enberg
On 3/9/07, Eric Dumazet [EMAIL PROTECTED] wrote: Cannot we use a flag in 'struct files_struct', set to one when the task is mono-thread (at task creation in fact), and set to 0 when it creates a new thread (or when someone remotely access to this struct files_struct in /proc/pid/fd/... ) How

Re: [PATCH 2/7] revoke: add f_light flag for struct file

2007-03-09 Thread Pekka Enberg
On 3/9/07, Eric Dumazet [EMAIL PROTECTED] wrote: Then just drop the fget_light() 'optimisation' and always take a reference (atomic on f_count) regardless of single-thread or not. Instead of dirtying f_light, just do the straightforward thing and be with it. That's what I did first but akpm

Re: [PATCH 2/7] revoke: add f_light flag for struct file

2007-03-09 Thread Pekka Enberg
On 3/9/07, Eric Dumazet [EMAIL PROTECTED] wrote: Then just drop the fget_light() 'optimisation' and always take a reference (atomic on f_count) regardless of single-thread or not. Instead of dirtying f_light, just do the straightforward thing and be with it. On 3/9/07, Pekka Enberg [EMAIL

Re: [PATCH] revoke: delayed file closing

2007-03-09 Thread Pekka Enberg
On 3/9/07, Pekka J Enberg [EMAIL PROTECTED] wrote: To fix this, change sys_revoke() not to close the actual revoked file immediately. Instead, we do filp_close() when the user does close(2) on the revoked file descriptor. Btw, this is safe because a filesystem implementing f_ops-revoke must

Re: [PATCH 7/7] revoke: wire up s390 system calls

2007-03-09 Thread Pekka Enberg
Hi Martin, Martin Schwidefsky wrote: Yes, please put me or Heiko on CC if you add system calls to s390. Ok, sorry about that. I would expect akpm to send it to you guys though whenever revoke graduates from -mm and not merge it to mainline. Pekka - To

Re: [PATCH 2/7] revoke: add f_light flag for struct file

2007-03-09 Thread Pekka Enberg
On Fri, Mar 09, 2007 at 12:13:35PM +0100, Eric Dumazet wrote: Then just drop the fget_light() 'optimisation' and always take a reference (atomic on f_count) regardless of single-thread or not. Instead of dirtying f_light, just do the straightforward thing and be with it. (that is :

Re: [PATCH 3/7] revoke: core code

2007-03-11 Thread Pekka Enberg
On Fri, 2007-03-09 at 10:15 +0200, Pekka J Enberg wrote: + again: + restart_addr = zap_page_range(vma, start_addr, end_addr - start_addr, + details); + + need_break = need_resched() || need_lockbreak(details-i_mmap_lock); + if (need_break) +

Re: [patch 4/4] [TULIP] Rev tulip version

2007-03-12 Thread Pekka Enberg
Hi, On 3/12/07, Valerie Henson [EMAIL PROTECTED] wrote: --- tulip-2.6-mm-linux.orig/drivers/net/tulip/tulip_core.c +++ tulip-2.6-mm-linux/drivers/net/tulip/tulip_core.c @@ -17,11 +17,11 @@ #define DRV_NAME tulip #ifdef CONFIG_TULIP_NAPI -#define DRV_VERSION1.1.14-NAPI /* Keep at

Re: [PATCH] [REVISED] net/ipv4/multipath_wrandom.c: check kmalloc() return value.

2007-03-12 Thread Pekka Enberg
On 3/12/07, Jarek Poplawski [EMAIL PROTECTED] wrote: So, maybe it's less evil to check those NULLs where possible and add some WARN_ONs here and there... No, it's much better to oops rather than paper over a bug. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the

Re: kernel BUG at mm/slab.c:610

2007-03-14 Thread Pekka Enberg
Hi Marco, On 3/14/07, Marco Berizzi [EMAIL PROTECTED] wrote: Hello everybody. Sorry for posting to this list, but I'm pretty lost. Don't worry, this is the proper mailing list for bug reports. On 3/14/07, Marco Berizzi [EMAIL PROTECTED] wrote: I don't think this is related to buggy hardware

Re: [BUG] Linux 2.6.20.2 - unable to handle kernel paging request - still accessing freed memory

2007-03-14 Thread Pekka Enberg
Hi Chris, On 3/10/07, Chris Rankin [EMAIL PROTECTED] wrote: It looks like 2.6.20.2 is still doing Bad Things in /sys. I have seen other reports of this too so can you please open a bug at bugzilla.kernel.org so this is not lost in the noise? - To unsubscribe from this list: send the line

Re: [BUG] Linux 2.6.20.2 - unable to handle kernel paging request - still accessing freed memory

2007-03-14 Thread Pekka Enberg
Hi Greg, I think there's some sort of reference counting problem with sysfs in 2.6.20 kernels. Can you please help us debug it further? On 3/10/07, Chris Rankin [EMAIL PROTECTED] wrote: It looks like 2.6.20.2 is still doing Bad Things in /sys. BUG: unable to handle kernel paging request at

Re: kernel BUG at mm/slab.c:610

2007-03-14 Thread Pekka Enberg
On 3/14/07, Marco Berizzi [EMAIL PROTECTED] wrote: Only to tell you, that on the console linux was printing this message: atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access hardware directly. Probably unrelated. CONFIG_SLAB_DEBUG should tell us what's corrupting the

Re: [PATCH 2/5] revoke: core code

2007-03-15 Thread Pekka Enberg
Hi Andrew, On Sun, 11 Mar 2007 13:30:49 +0200 (EET) Pekka J Enberg [EMAIL PROTECTED] wrote: On 3/16/07, Andrew Morton [EMAIL PROTECTED] wrote: n all system calls must return long. Fixed. On 3/16/07, Andrew Morton [EMAIL PROTECTED] wrote: so the modification of vm_flags is

Re: [BUG] Linux 2.6.20.2 - unable to handle kernel paging request - still accessing freed memory

2007-03-16 Thread Pekka Enberg
On 3/16/07, Greg KH [EMAIL PROTECTED] wrote: Is there any way you can use 'git bisect' to try to track down the root cause of this? Chris, If 2.6.19 works for you, could you please do a git bisect for this bug? See the following URL for details:

Re: [PATCH 1/3] revoke: misc fixes

2007-03-16 Thread Pekka Enberg
On 3/16/07, Nick Piggin [EMAIL PROTECTED] wrote: Also, a down_write_trylock attempt inside i_mmap_lock should be a valid optimisation. I am not sure what you're thinking here. down_write_trylock acquires -mmap_sem which can deadlock with -i_mmap_lock, no? - To unsubscribe from this list: send

Re: [BUG] Linux 2.6.20.2 - unable to handle kernel paging request - still accessing freed memory

2007-03-16 Thread Pekka Enberg
Hi Chris, On 3/16/07, Chris Rankin [EMAIL PROTECTED] wrote: That would take ages - the only reason I kept on plugging away with winecfg last night was because I was fairly certain the kernel was going to oops eventually (which it did). But when exactly would I be able to declare a kernel good

Re: [PATCH 2/5] revoke: core code

2007-03-16 Thread Pekka Enberg
On 3/16/07, Alan Cox [EMAIL PROTECTED] wrote: Serious question - do we actually need revoke() on a normal file ? BSD has never had this, SYS5 has never had this. It's needed for forced unmount (bits of it anyway) and partial-revocation in SLIM. - To unsubscribe from this list: send the line

Re: [PATCH 2/5] revoke: core code

2007-03-16 Thread Pekka Enberg
On 3/16/07, Alan Cox [EMAIL PROTECTED] wrote: I'm not sure that running do_fsync() will guarantee that all sys_write() callers will have finished their syscall. Probably they will have, in practice. But there is logic in the sync paths to deliberately bale out if we're competing with

Re: [PATCH 2/5] revoke: core code

2007-03-16 Thread Pekka Enberg
On 3/16/07, Alan Cox [EMAIL PROTECTED] wrote: Serious question - do we actually need revoke() on a normal file ? BSD has never had this, SYS5 has never had this. On 3/16/07, Pekka Enberg [EMAIL PROTECTED] wrote: It's needed for forced unmount (bits of it anyway) and partial-revocation

Re: [PATCH 2/5] revoke: core code

2007-03-16 Thread Pekka Enberg
On 3/16/07, Andrew Morton [EMAIL PROTECTED] wrote: However, modifying i_size like this might be a problem - the inode could be dirty and it'll get written to disk! Perhaps we could change i_size_read() to cheat and to return zero if there's a revoke in progress. I don't think we can actually

Re: [PATCH] Re: NAK new drivers without proper power management?

2007-02-11 Thread Pekka Enberg
On 2/11/07, Rafael J. Wysocki [EMAIL PROTECTED] wrote: Unfortunately it has to be done in one shot for all of the known good drivers to avoid user-observable regressions. No you don't. You can make it a config option that defaults to n during a transition period. - To unsubscribe from this

Re: somebody dropped a (warning) bomb

2007-02-13 Thread Pekka Enberg
On 2/13/07, Sergei Organov [EMAIL PROTECTED] wrote: May I suggest another definition for a warning being entirely sucks? The warning is entirely sucks if and only if it never has true positives. In all other cases it's only more or less sucks, IMHO. You're totally missing the point. False

Re: somebody dropped a (warning) bomb

2007-02-13 Thread Pekka Enberg
On 2/13/07, Sergei Organov [EMAIL PROTECTED] wrote: With almost any warning out there one makes more or less efforts to suppress the warning where it gives false positives, isn't it? Yes, as long it's the _compiler_ that's doing the effort. You shouldn't need to annotate the source just to

Re: [patch 07/21] Xen-paravirt: remove ctor for pgd cache

2007-02-16 Thread Pekka Enberg
On 2/16/07, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote: Remove the ctor for the pgd cache. There's no point in having the cache machinery do this via an indirect call when all pgd are freed in the one place anyway. The reason we have slab constructors and destructors is to _avoid_

Re: [PATCH 12/44 take 2] [UBI] allocation unit implementation

2007-02-19 Thread Pekka Enberg
On 2/17/07, Artem Bityutskiy [EMAIL PROTECTED] wrote: +void *ubi_kzalloc(size_t size) +{ + void *ret; + + ret = kzalloc(size, GFP_KERNEL); + if (unlikely(!ret)) { + ubi_err(cannot allocate %zd bytes, size); + dump_stack(); + return

Re: forced umount?

2007-03-17 Thread Pekka Enberg
On 3/17/07, Mike Snitzer [EMAIL PROTECTED] wrote: Thanks for the heads up; its good to see that Pekka Enberg's work has continued. I actually stumbled onto that line of work earlier while searching for more info on Tigran Aivazian's forced unmount (badfs) patches:

Re: Bug in pci_restore_msi_state

2007-03-17 Thread Pekka Enberg
On 3/17/07, Thomas Meyer [EMAIL PROTECTED] wrote: Hello everybody. I get this bug after suspending to disk twice: http://m3y3r.de/bilder/Bug-pci_restore_msi_state.png This happens with current git head cd05a1f818073a623455a58e756c5b419fc98db9. If you know a kernel that works, please

Re: 2.6.20.3: kernel BUG at mm/slab.c:597 try#2

2007-03-19 Thread Pekka Enberg
On 3/19/07, Andrew Morton [EMAIL PROTECTED] wrote: BUG_ON(!PageSlab(page)); that's seriously screwed up. Do you have CONFIG_DEBUG_SLAB enabled? If not, please enable it and retest. This is scary. Looking at disassembly of the OOPS: Disassembly of section .text: .text:

Re: 2.6.20.3: kernel BUG at mm/slab.c:597 try#2

2007-03-19 Thread Pekka Enberg
On 3/19/07, Pekka Enberg [EMAIL PROTECTED] wrote: EIP is at kmem_cache_free+0x29/0x5a eax: c180 ebx: f0ae12c0 ecx: c18f73c0 edx: c180 esi: c1919de0 edi: ebp: 1000 esp: f1fe7e14 ds: 007b es: 007b ss: 0068 But somehow eax and edx have the same value 0xc180

Re: 2.6.20.3: kernel BUG at mm/slab.c:597 try#2

2007-03-19 Thread Pekka Enberg
On 3/19/07, Pekka Enberg [EMAIL PROTECTED] wrote: You can see that mempool_free is passing a NULL pointer to kmem_cache_free() which doesn't handle it properly. The NULL pointer comes from bio_free() where -bi_io_vec is NULL because nr_iovecs passed to bio_alloc_bioset() was zero. The question

Re: [PATCH] slab: deal with NULL pointers passed to kmem_cache_free

2007-03-19 Thread Pekka Enberg
On 3/19/2007, Andrew Morton [EMAIL PROTECTED] wrote: Would prefer to do: static inline void kmem_cache_free_if_not_null(struct kmem_cache *cachep, void *objp) { if (objp) kmem_cache_free(cachep, objp); } so that we

Re: [PATCH] slab: deal with NULL pointers passed to kmem_cache_free

2007-03-20 Thread Pekka Enberg
On 3/19/07, Andrew Morton [EMAIL PROTECTED] wrote: The BUG_ON (at least) should probably be moved into CONFIG_DEBUG_SLAB. No it shouldn't. Letting non-slab pages pass through causes nasty and hard to debug problems which is why we have the BUG_ONs in the first place:

Re: [PATCH] slab: deal with NULL pointers passed to kmem_cache_free

2007-03-20 Thread Pekka Enberg
On 3/19/07, Andrew Morton [EMAIL PROTECTED] wrote: This is a super-hot path. Super-hot exactly where? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please

Re: [PATCH] slab: deal with NULL pointers passed to kmem_cache_free

2007-03-21 Thread Pekka Enberg
On 3/21/07, Jarek Poplawski [EMAIL PROTECTED] wrote: I think Pekka was right (it looks he changed his mind now) something should be done here. I think something like this should be a minimum: BUG_ON(!objp || virt_to_cache(objp) != cachep); to show distinctly what's going on. No, if we were

Re: [RFC, PATCH] SLAB : [NUMA] keep nodeid in struct page instead of struct slab

2007-03-21 Thread Pekka Enberg
On 3/21/07, Eric Dumazet [EMAIL PROTECTED] wrote: In order to avoid a cache miss in kmem_cache_free() on NUMA and reduce hot path length, we could exploit the following common facts. It would be nice if you could cc me for slab patches. On 3/21/07, Eric Dumazet [EMAIL PROTECTED] wrote:

Re: [RFC, PATCH] SLAB : [NUMA] keep nodeid in struct page instead of struct slab

2007-03-21 Thread Pekka Enberg
On 3/21/07, Eric Dumazet [EMAIL PROTECTED] wrote: +#ifdef KEEP_NODEID_IN_PAGE + /* kmem_cache addresses must be multiple of 64 */ + cache_cache.buffer_size = ALIGN(cache_cache.buffer_size, + max(64, cache_line_size())); +#else

Re: [PATCH] SLAB : Use num_possible_cpus() in enable_cpucache()

2007-03-21 Thread Pekka Enberg
On 3/21/07, Eric Dumazet [EMAIL PROTECTED] wrote: As most shiped linux kernels are now compiled with CONFIG_SMP, there is no way a preprocessor #if can detect if the machine is UP or SMP. Better to use num_possible_cpus(). Looks good to me. Acked-by: Pekka Enberg [EMAIL PROTECTED

Re: [PATCH] SLAB : Dont allocate empty shared caches

2007-03-21 Thread Pekka Enberg
is safe. Looks good to me. Acked-by: Pekka Enberg [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] slab: deal with NULL pointers passed to kmem_cache_free

2007-03-21 Thread Pekka Enberg
On 3/21/07, Rafael J. Wysocki [EMAIL PROTECTED] wrote: IMHO one way to find them is to actually slow down kmem_cache_free() and see where the performance is hurt. Yeah, I'll try to sneak a patch past Andrew. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of

Re: [RFC, PATCH] SLAB : [NUMA] keep nodeid in struct page instead of struct slab

2007-03-21 Thread Pekka Enberg
On 3/21/07, Christoph Lameter [EMAIL PROTECTED] wrote: None of that please. The page flags already contain a node number that is accessible via page_to_nid(). Just make sure that we never put a slab onto the wrong node. Sounds good. Do you know for a fact that we don't or are you just afraid

Re: [RFC, PATCH] SLAB : [NUMA] keep nodeid in struct page instead of struct slab

2007-03-21 Thread Pekka Enberg
On 3/21/07, Eric Dumazet [EMAIL PROTECTED] wrote: Last time I checked 'struct page', they was no nodeid in it. Hmm, page_to_nid() in include/linx/mm.h doesn't agree with you: #ifdef NODE_NOT_IN_PAGE_FLAGS extern int page_to_nid(struct page *page); #else static inline int page_to_nid(struct

Re: [RFC, PATCH] SLAB : [NUMA] keep nodeid in struct page instead of struct slab

2007-03-21 Thread Pekka Enberg
On 3/21/2007, Andi Kleen [EMAIL PROTECTED] wrote: You can always use numa emulation on x86-64. Boot with numa=fake=NODES Yes, I know, but I don't have a x86-64 box either =) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED]

Re: [PATCH] slab: deal with NULL pointers passed to kmem_cache_free

2007-03-21 Thread Pekka Enberg
On 3/21/2007, Andrew Morton [EMAIL PROTECTED] wrote: Thing is, such a patch would amount to adding a test-for-NULL to codepaths which we *know* do not need it. There is no point in doing that. Now you're just being stubborn, Andrew ;-). The extra check does not matter much at all for most

Re: [RFC] NUMA : could we introduce virt_to_nid() ?

2007-03-23 Thread Pekka Enberg
On 3/23/07, Eric Dumazet [EMAIL PROTECTED] wrote: Checking Christoph quicklist implementation, I found the same cache miss in free() than SLAB has. /* common implementation * int virt_to_nid(const void *addr) { struct page *page = virt_to_page(addr); return page_to_nid(page); }

Re: [-mm patch] fs/revoke.c: cleanups (and bugfix for 64bit systems)

2007-03-24 Thread Pekka Enberg
Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Looks good. Thanks! Acked-by: Pekka Enberg [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please

Re: kmem_cache_create loop for find the proper gfporder

2007-03-25 Thread Pekka Enberg
On 3/25/07, Bin Chen [EMAIL PROTECTED] wrote: It is done by increase gfporder for low number to high(possibly 0 to MAX_GFP_ORDER). But why increase the gfporder(or slab size) can decrease the internal fragmentation?) A simple example, suppose the slab management stuff is kept off-slab, if the

Re: Reiser4. BEST FILESYSTEM EVER.

2007-04-07 Thread Pekka Enberg
On 4/7/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I checked what bonnie++ actually writes to its test files, for you. It is about 98-99% zeros. Still, the results record sequential reads, of 232,729 K/sec, nearly four times the physical disk read rate, 63,160 K/sec, of the hard drive.

Re: REISER4 FOR INCLUSION IN THE LINUX KERNEL.

2007-04-09 Thread Pekka Enberg
On 4/9/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: YOU GUYS WILL LAUGH ABOUT THIS: No, I am crying actually. Dear post-masters, can we have this thread shit-canned, please? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED]

Re: PATCH 7/8] lguest: the block driver

2007-04-10 Thread Pekka Enberg
Hi Rusty, On 4/10/07, Rusty Russell [EMAIL PROTECTED] wrote: +/* Jens gave me this nice helper to end all chunks of a request. */ +static void end_entire_request(struct request *req, int uptodate) +{ + if (end_that_request_first(req, uptodate, req-hard_nr_sectors)) + BUG();

Re: PATCH 7/8] lguest: the block driver

2007-04-10 Thread Pekka Enberg
(); + add_disk_randomness(req-rq_disk); + blkdev_dequeue_request(req); + end_that_request_last(req, uptodate); +} On 4/10/07, Pekka Enberg [EMAIL PROTECTED] wrote: Perhaps we should move this to generic code (i.e. block/ll_rw_blk.c)? Uhm, I am bit confused now. Why don't you just

Re: PATCH 7/8] lguest: the block driver

2007-04-10 Thread Pekka Enberg
On 4/11/07, Rusty Russell [EMAIL PROTECTED] wrote: What a question! end_request() doesn't end a request! What a crazy idea! Aah, indeed, end_request() uses req-hard_cur_sectors while end_entire_request() uses req-hard_nr_sectors which I missed. On 4/11/07, Rusty Russell [EMAIL PROTECTED]

Re: Why kmem_cache_free occupy CPU for more than 10 seconds?

2007-04-11 Thread Pekka Enberg
On 4/11/07, Zhao Forrest [EMAIL PROTECTED] wrote: We're using RHEL5 with kernel version 2.6.18-8.el5. When doing a stress test on raw device for about 3-4 hours, we found the soft lockup message in dmesg. I know we're not reporting the bug on the latest kernel, but does any expert know if this

Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]

2007-04-15 Thread Pekka Enberg
On 4/15/07, hui Bill Huey [EMAIL PROTECTED] wrote: The perception here is that there is that there is this expectation that sections of the Linux kernel are intentionally churn squated to prevent any other ideas from creeping in other than of the owner of that subsytem Strangely enough, my

Re: [-mm patch] UNION_FS must depend on SLAB

2007-02-19 Thread Pekka Enberg
On 2/20/07, Adrian Bunk [EMAIL PROTECTED] wrote: CC fs/unionfs/copyup.o /home/bunk/linux/kernel-2.6/linux-2.6.20-mm2/fs/unionfs/copyup.c: In function 'create_parents_named': /home/bunk/linux/kernel-2.6/linux-2.6.20-mm2/fs/unionfs/copyup.c:620: error: 'malloc_sizes' undeclared (first use

Re: [PATCH 1/3] slab: introduce krealloc

2007-02-21 Thread Pekka Enberg
On 2/21/07, Arjan van de Ven [EMAIL PROTECTED] wrote: please mark this one __must_check.. not storing realloc() return values is one of the more nasty types of bugs... but gcc can help us greatly here ;) So I guess we want the same thing for the other allocator functions (__kmalloc et al) as

Re: [PATCH 1/3] slab: introduce krealloc

2007-02-21 Thread Pekka Enberg
Christoph Lameter wrote: Well could you check ksize for the old object first and if ksize = new size then just skip the copy? I think this may allow you to get rid of the ksize callers. And not reallocate at all, right? I thought about that but then you wouldn't be able to use realloc() to

Re: [PATCH] slab: ensure cache_alloc_refill terminates

2007-02-21 Thread Pekka Enberg
On Wed, 21 Feb 2007, Pekka J Enberg wrote: + */ + BUG_ON(slabp-inuse 0 || slabp-inuse = cachep-num); + while (slabp-inuse cachep-num batchcount--) { On 2/21/07, Christoph Lameter [EMAIL PROTECTED] wrote: I think you only need to check for 0. If

Re: [PATCH 1/3] slab: introduce krealloc

2007-02-21 Thread Pekka Enberg
Hi Christoph, Christoph Lameter wrote: 1. Just do not allow shrinking via realloc. Probably no big loss and best performance. Not a big loss if you can afford the wasted memory. But, I don't think we should do this, there's no way for the caller to know that we will hold on to the memory

Re: [PATCH 1/3] slab: introduce krealloc

2007-02-21 Thread Pekka Enberg
On 2/21/07, Christoph Lameter [EMAIL PROTECTED] wrote: Why not? Its a realloc call and these are the classic semantics of realloc. Otherwise realloc will always move the memory. Well, as a reference, the user-space equivalent is defined in SUSv3 as: The realloc() function shall change the

Re: [-mm patch] UNION_FS must depend on SLAB

2007-02-21 Thread Pekka Enberg
Hi Andrew, Andrew Morton wrote: Problem is, it doesn't seem that we'll be merging unionfs any time soon so we shouldn't be adding slab infrastructure on its behalf. And I'd prefer not to have to carry slab changes in a filesystem tree. I think we can merge krealloc without unionfs. I'll

Re: [-mm patch] UNION_FS must depend on SLAB

2007-02-21 Thread Pekka Enberg
Pekka Enberg wrote: The ksize exports we can add later if unionfs is to be merged. Actually, we probably don't need it after the krealloc optimizations. I think we need a new unionfs patch too... :) Pekka - To unsubscribe from this list: send the line

Re: SLUB: The unqueued Slab allocator

2007-02-22 Thread Pekka Enberg
Hi Christoph, On 2/22/07, Christoph Lameter [EMAIL PROTECTED] wrote: This is a new slab allocator which was motivated by the complexity of the existing code in mm/slab.c. It attempts to address a variety of concerns with the existing implementation. So do you want to add a new allocator or

Re: [PATCH 02/29] mm: slab allocation fairness

2007-02-21 Thread Pekka Enberg
On 2/21/07, Peter Zijlstra [EMAIL PROTECTED] wrote: [AIM9 results go here] Yes please. I would really like to know what we gain by making the slab even more complex. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More

Re: [PATCH 08/29] mm: kmem_cache_objs_to_pages()

2007-02-21 Thread Pekka Enberg
Hi Peter, On 2/21/07, Peter Zijlstra [EMAIL PROTECTED] wrote: Provide a method to calculate the number of pages needed to store a given number of slab objects (upper bound when considering possible partial and free slabs). So how does this work? You ask the slab allocator how many pages you

Re: [PATCH 08/29] mm: kmem_cache_objs_to_pages()

2007-02-22 Thread Pekka Enberg
Hi Peter, On Wed, 2007-02-21 at 17:47 +0200, Pekka Enberg wrote: So how does this work? You ask the slab allocator how many pages you need for a given number of objects and then those pages are available to it via the page allocator? Can other users also dip into those reserves? On 2/22

Re: [PATCH 08/29] mm: kmem_cache_objs_to_pages()

2007-02-22 Thread Pekka Enberg
On 2/22/07, Pekka Enberg [EMAIL PROTECTED] wrote: So you are only interested in rough estimation of how much many pages you need for a given amount of objects? Why not use ksize() for that then? Uhm, I obviously meant, why not expose obj_size() instead. - To unsubscribe from this list: send

Re: [RFC/PATCH] revokeat/frevoke system calls V5

2007-02-25 Thread Pekka Enberg
Hi Alan, On 2/26/07, Alan [EMAIL PROTECTED] wrote: Whats the status on this, I was suprised to see something so important just go dead ? It's not dead. You can find the latest patches here: http://www.cs.helsinki.fi/u/penberg/linux/revoke/patches/ and user-space tests here:

Re: [BUG] Linux 2.6.20.1 - unable to handle kernel paging request - accessing freed memory?

2007-02-27 Thread Pekka Enberg
Hi, On 2/26/07, Chris Rankin [EMAIL PROTECTED] wrote: BUG: unable to handle kernel paging request at virtual address 6b6b6ceb [snip] EIP is at module_put+0x20/0x52 eax: 6b6b6ceb ebx: 6b6b6b6b ecx: 0001 edx: e5bf esi: e9040b08 edi: 6b6b6b6b ebp: eae0bb3c esp: e5bf0f58 ds:

Re: [Alsa-devel] [BUG] Linux 2.6.20.1 - unable to handle kernel paging request - accessing freed memory?

2007-02-27 Thread Pekka Enberg
On 2/27/07, Chris Rankin [EMAIL PROTECTED] wrote: Hmm, this bug looks interesting: http://www.ussg.iu.edu/hypermail/linux/kernel/0702.3/0514.html Yes, my machine *is* a dual P4 with HT enabled... Yeah, but the oops looks more like a reference counting problem with sysfs dentries. No harm in

Re: [PATCH 2/2] revoke: break cow for private mappings

2007-03-28 Thread Pekka Enberg
On 3/28/07, Nick Piggin [EMAIL PROTECTED] wrote: + ret = get_user_pages(tsk, tsk-mm, vma-vm_start, + vma-vm_end-vma-vm_start, 1, 1, NULL, + NULL); get_user_pages length argument is in # of pages, rather than

Re: [QUESTION] check for mem in slab

2007-03-30 Thread Pekka Enberg
On 3/30/07, Heiko Carstens [EMAIL PROTECTED] wrote: in file mm/slab.c and routine kmem_cache_init() I found there is no checking for allocated memory on line: /* 4) Replace the bootstrap head arrays */ { struct array_cache *ptr; ptr =

Re: [powerpc] RS/6000 43p-150 no longer boots as of 2.6.18

2007-03-31 Thread Pekka Enberg
Hi Peter, On 3/31/07, Peter Samuelson [EMAIL PROTECTED] wrote: ...and here it hangs. This happened between 2.6.17-git21 and -git22. .config is attached. I'd be happy to test patches and provide more information. You could try git bisect to find the exact commit that broke your kernel:

Re: mcdx -- do_request(): non-read command to cd!!

2007-04-01 Thread Pekka Enberg
On 3/31/07, Rene Herman [EMAIL PROTECTED] wrote: There's quite a bit of noise in dmesg though. Repeated 5 times: ===BUG: scheduling while atomic: mount/0x0001/1166 [c1170bff] __sched_text_start+0x57/0x574 [c1171964] schedule_timeout+0x70/0x8f [c10199b2] process_timeout+0x0/0x5

Re: mcdx -- do_request(): non-read command to cd!!

2007-04-01 Thread Pekka Enberg
On 4/1/07, Pekka Enberg [EMAIL PROTECTED] wrote: Looks like mcdx_xfer is sleeping while holding q-queue_lock. The attached (untested) patch should fix it. You also need to add a spin_lock_irq() before the call to end_request() to Jens' patch. - To unsubscribe from this list: send the line

Re: usb hid: reset NumLock

2007-04-01 Thread Pekka Enberg
On 3/30/07, Pete Zaitcev [EMAIL PROTECTED] wrote: Dell people (Stuart and Charles) complained that on some USB keyboards, if BIOS enables NumLock, it stays on even after Linux has started. Since we always start with NumLock off, this confuses users. Quick double dab at NumLock fixes it, but it's

Re: mcdx -- do_request(): non-read command to cd!!

2007-04-02 Thread Pekka Enberg
Hi Rene, On 4/2/07, Rene Herman [EMAIL PROTECTED] wrote: [EMAIL PROTECTED]:~# dd if=/dev/mcdx0 of=/dev/null bs=2048 0+0 records in 0+0 records out 0 bytes (0 B) copied, 0.000221955 seconds, 0.0 kB/s [EMAIL PROTECTED]:~# This I know isn't: [EMAIL PROTECTED]:~# readcd dev=/dev/mcdx0 f=/dev/null

Re: mcdx -- do_request(): non-read command to cd!!

2007-04-04 Thread Pekka Enberg
On 4/4/07, Rene Herman [EMAIL PROTECTED] wrote: Taking forever to reproduce in as far as getting the oops. The thing is now just locking hard each time. Will keep on trying... Can you get anything out with sysrq-t? The original oops would be enough to conclude it's a double-free if it weren't

Re: New linux arch

2008-01-07 Thread Pekka Enberg
Hi Michael, On Jan 7, 2008 1:29 PM, Michal Simek [EMAIL PROTECTED] wrote: Is it possible to create git repository in git.kernel.org for Microblaze cpu? You need to ask the kernel.org administrators for that: http://www.kernel.org/faq/#account On Jan 7, 2008 1:29 PM, Michal Simek [EMAIL

Re: New linux arch

2008-01-07 Thread Pekka Enberg
Hi Michal, On Jan 7, 2008 3:00 PM, Michal Simek [EMAIL PROTECTED] wrote: You can have as many maintainers as you want but you probably don't want to make it too many. There aren't any official responsibilities as a maintainer, it really depends on how much time and effort you're willing

Re: New linux arch

2008-01-08 Thread Pekka Enberg
Hi Bryan, On Jan 8, 2008 10:28 AM, Bryan Wu [EMAIL PROTECTED] wrote: 1. Push patches to LKML when merge window open (2 weeks after a stable kernel version release, for example 2 weeks after 2.6.24 released) You shouldn't wait for the merge window to open to send patches for review for the

Re: slab quirks in DEBUG, ctor, and initialization

2007-12-17 Thread Pekka Enberg
Hi John, On Dec 17, 2007 5:47 PM, John Reiser [EMAIL PROTECTED] wrote: In mm/slab.c, the DEBUG variant of cache_alloc_debugcheck_after might call cachep-ctor(objp, cachep, 0); but the non-DEBUG variant does absolutely nothing. idr_pre_get is a routine which notices the difference. How

Re: almost daily Kernel oops with 2.6.23.9 - and now 2.6.23.11 as well

2007-12-20 Thread Pekka Enberg
Hi, On Dec 20, 2007 4:38 PM, David Newall [EMAIL PROTECTED] wrote: and another one, this time tainted with the nvidia module: 5194.130985] Unable to handle kernel paging request at 0300 RIP: Numbers like that don't suggest hardware faults. All those zeros: It's far too

Re: Major regression on hackbench with SLUB (more numbers)

2007-12-21 Thread Pekka Enberg
Hi, Christoph Lameter [EMAIL PROTECTED] wrote: In an extreme case (boot with slub_min_order=9 to get huge page sized slabs) SLUB can win against SLAB: N=10 Time: 0.338 Minimally faster N=20 Time: 0.560 10% faster N=50 Time: 1.353 15% faster On Dec 21, 2007 2:09 PM,

Re: Major regression on hackbench with SLUB (more numbers)

2007-12-21 Thread Pekka Enberg
thought it might be a bug but couldn't figure it out. The patch looks good to me too, Christoph. Reviewed-by: Pekka Enberg [EMAIL PROTECTED] On Dec 22, 2007 1:17 AM, Ingo Molnar [EMAIL PROTECTED] wrote: And i hereby nominate Pekka as SLUB/SLAB co-maintainer and spokesperson ;-) Heh, thanks

Re: [PATCH] SC26XX: New serial driver for SC2681 uarts

2007-12-22 Thread Pekka Enberg
Hi Thomas, On Dec 5, 2007 11:25 AM, Thomas Bogendoerfer [EMAIL PROTECTED] wrote: These: +#define READ_SC(p, r)readb((p)-membase + RD_##r) +#define WRITE_SC(p, r, v)writeb((v), (p)-membase + WR_##r) and these: +#define READ_SC_PORT(p, r) read_sc_port(p,

Re: Major regression on hackbench with SLUB (more numbers)

2007-12-22 Thread Pekka Enberg
Hi, On Dec 22, 2007 2:37 PM, Andi Kleen [EMAIL PROTECTED] wrote: Removing an interface that exposes lots of internal details when you rewrite the subsystem and those internal details all change seems like a good reason to me. Yeah but then again removing an interface that has been around for

Re: Major regression on hackbench with SLUB (more numbers)

2007-12-22 Thread Pekka Enberg
Hi Andi, On Dec 22, 2007 2:54 PM, Andi Kleen [EMAIL PROTECTED] wrote: Yeah but then again removing an interface that has been around for ever Version 2.1 hasn't been around forever and at least slabtop does not work over version number changes in my experience. True but the default

Re: [PATCH] slub: /proc/slabinfo ABI compatibility

2007-12-22 Thread Pekka Enberg
Hi Ingo, On Dec 22, 2007 3:14 PM, Ingo Molnar [EMAIL PROTECTED] wrote: Also please apply the cleanup patch below, it fixes 34 checkpatch errors and warnings in mm/slub.c. Those are already fixed in -mm:

Re: [PATCH] slub: /proc/slabinfo ABI compatibility

2007-12-22 Thread Pekka Enberg
'count_partial' Looks good. Thanks! Reviewed-by: Pekka Enberg [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http

Re: [PATCH] slub: /proc/slabinfo ABI compatibility

2007-12-22 Thread Pekka Enberg
it a second look ;-) Sure, I'm fine with that. Can you Andrew please drop mine and use Ingo's instead? Acked-by: Pekka Enberg [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http

Re: [BUG 2.6.24-rc3-git6] SLUB's ksize() fails for size 2048.

2007-12-02 Thread Pekka Enberg
; - page = get_object_page(object); + page = virt_to_head_page(object); BUG_ON(!page); + + if (unlikely(!PageSlab(page))) + return PAGE_SIZE compound_order(page); + s = page-slab; BUG_ON(!s); Looks good to me. Reviewed-by: Pekka Enberg

Re: [feature] automatically detect hung TASK_UNINTERRUPTIBLE tasks

2007-12-03 Thread Pekka Enberg
Hi, On Mon, Dec 03, 2007 at 12:59:00PM +0100, Ingo Molnar wrote: audit thousands of callsites in 8 million lines of code first is a nice euphemism for hiding from the blame forever. We had 10 years for it On Dec 3, 2007 2:13 PM, Andi Kleen [EMAIL PROTECTED] wrote: Ok your approach is then

Re: [PATCH] Add EXPORT_SYMBOL(ksize);

2007-12-03 Thread Pekka Enberg
Hi, On Mon, Dec 03, 2007 at 08:41:44PM +0900, Tetsuo Handa wrote: We couldn't know how much memory was allocated by kmalloc() in 2.4 era, and we can know it 2.6 era. But are we going back to 2.4 era for out-of-tree kernel modules? On Dec 3, 2007 3:57 PM, Adrian Bunk [EMAIL PROTECTED]

Re: [PATCH] pktcdvd : add kobject_put when kobject register fails

2007-12-03 Thread Pekka Enberg
Hi Dave, On Dec 4, 2007 3:31 AM, Dave Young [EMAIL PROTECTED] wrote: Kobject_put should be called when kobject register functioin fails, so the the kobj ref count touch zero and then the proper cleanup routines will be called. [snip] diff -upr linux/drivers/block/pktcdvd.c

[PROBLEM] uml doesn't compile on i386

2007-11-23 Thread Pekka Enberg
Hi, Current git head doesn't compile. Looks like fall-out from the x86 merge? [EMAIL PROTECTED]:~/src/linux/uml-2.6$ make ARCH=um SYMLINK arch/um/include/kern_constants.h SYMLINK arch/um/include/sysdep make[1]: `arch/um/sys-i386/user-offsets.s' is up to date. CHK

Re: [PROBLEM] uml doesn't compile on i386

2007-11-23 Thread Pekka Enberg
Hi, On Fri, Nov 23, 2007 at 10:52:06AM +0200, Pekka Enberg wrote: Current git head doesn't compile. Looks like fall-out from the x86 merge? On Nov 23, 2007 12:13 PM, WANG Cong [EMAIL PROTECTED] wrote: Hmm, I believe this patch[1] from Jeff can solve the problem. ;-) [1] http://lkml.org/lkml

  1   2   3   4   5   6   7   8   9   10   >