> > so LIFO might even end up performing better on SMP, when compared to the
> > current allocator.
>
> > (although there is a better way to solve this on SMP, by doing per-CPU
> > freelists, but anyway)
>
> Could you combine the two? I'm thinking about having a "last CPU"
> index in each block header, and a CPU first searches for an available
> block that was last used by it (in FIFO order), and only steals from
> another CPU if it has trouble.
>
> While there are still SMP inefficiencies, this lets global combining
> take place while preserving the essential processor affinity.
instead of 'mine' and 'others', rather think in terms of 'local' and
'global' freelist, where we disallow cross-stealing. On certain CPUs we
have cache-traffic performance counters, so we can estimate the number
of 'hot' cachelines within a local hostlist:
[2.3 stuff]
while (L2_cache_size < hot_cachelines_in_local_hotlist) {
free_page(tail_of_local_hotlist);
hot_cachelines_in_local_hotlist -= delta;
}
this might sound like serious overkill, but once we start thinking in
terms of 1-2-4+ megs of per-CPU L2 cache (UltraSparc(?), Xeon), it makes
sense. A 2M L2 cache can hold 512 full pages!
this way if eg. a process trashes through it's L2 cache, the hotlist will
be released next time around, while a process with nice locality preserves
the hotlist.
'cachelines_in_pool' and 'cachelines_kicked_since_last_time' can be only
an estimated value, based on the performance counters. We might specify a
weight to free_page(), this way aged pages freed in try_to_swap_out() are
considered 'cold' (and might not even be added), while young private dirty
pages freed after process exit (say the stack) are considered 'hot'.
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html