Ravikiran G Thirumalai <[email protected]> wrote:
>
> > OK. That's a bit nasty, isn't it? It can work well or poorly for
> > different people depending upon vagaries of .config and the linker.
> >
> > We should find out what it was sharing _with_. Could you please run
> >
> > nm -n vmlinux| grep -C5 dirty_exceeded
>
> ffffffff805290c0 b irq_dir
> ffffffff80529838 b root_irq_dir
> ffffffff80529880 B max_pfn
> ffffffff80529888 B min_low_pfn
> ffffffff80529890 B max_low_pfn
> ffffffff80529900 B nr_pagecache
> ffffffff80529908 B nr_swap_pages
> ffffffff80529980 b boot_pageset
> ffffffff8052a980 B laptop_mode
> ffffffff8052a984 B block_dump
> ffffffff8052a988 b dirty_exceeded
> ffffffff8052a990 b total_pages
> ffffffff8052a998 B nr_pdflush_threads
> ffffffff8052a9a0 b last_empty_jifs
> ffffffff8052a9c0 B slab_reclaim_pages
> ffffffff8052a9c4 b slab_break_gfp_order
> ffffffff8052a9c8 b g_cpucache_up
> ffffffff8052a9d0 b cache_chain
> ffffffff8052a9e0 b cache_chain_sem
> ffffffff8052aa00 b offslab_limit
> ffffffff8052aa08 B page_cluster
>
> Maybe slab_reclaim_pages is the culprit?
>
I guess so - pretty much everything else there should be in __read_mostly
anwyay, apart from nr_pagecache.
slab_reclaim_pages is just a silly beancounting thing for overcommit. We
could give it the approximate-counting treatment like pagecache_acct() I
guess.
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
