lkml.org 
[lkml]   [2004]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [pagevec] resize pagevec to O(lg(NR_CPUS))
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?

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

\
 
 \ /
  Last update: 2005-03-22 14:06    [W:0.052 / U:0.332 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site