Re: [pagevec] resize pagevec to O(lg(NR_CPUS))

[Andrew Morton]

William Lee Irwin III <wli@xxxxxxxxxxxxxx> wrote:
>
> William Lee Irwin III <wli@xxxxxxxxxxxxxx> wrote:
> >> A large stream of faults to map in a file will blow L1 caches of the
> >>  sizes you've mentioned at every kernel/user context switch. 256 distinct
> >>  cachelines will very easily be referenced between faults. MAP_POPULATE
> >>  and mlock() don't implement batching for either ->page_table_lock or
> >>  ->tree_lock, so the pagevec point is moot in pagetable instantiation
> >>  codepaths (though it probably shouldn't be).
> 
> On Sun, Sep 12, 2004 at 12:42:56AM -0700, Andrew Morton wrote:
> > Instantiation via normal fault-in becomes lock-intensive once you have
> > enough CPUs.  At low CPU count the page zeroing probably preponderates.
> 
> But that's mm->page_table_lock, for which pagevecs aren't used,

It is zone->lru_lock and pagevecs are indeed used.  See
do_anonymous_page->lru_cache_add_active.

> On Sun, Sep 12, 2004 at 12:42:56AM -0700, Andrew Morton wrote:
> > Possibly.  I wouldn't bother converting anything unless a profiler tells
> > you to though.
> 
> mlock() is the case I have in hand, though I've only heard of it being
> problematic on vendor kernels. MAP_POPULATE is underutilized in
> userspace thus far, so I've not heard anything about it good or bad.
> 

If you're referring to mlock() of an anonymous vma then that should all go
through do_anonymous_page->lru_cache_add_active anyway?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/