Messages in this thread | | | Date | Mon, 13 Sep 2004 19:57:31 -0700 | From | Andrew Morton <> | Subject | Re: [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/
| |