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

Andrew Morton
2004-09-14T03:02:39Z

William Lee Irwin III <wli@holomorphy.com> wrote:
>
> William Lee Irwin III <wli@holomorphy.com> 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?