On 22-10-08 11:25, Ray Kinsella wrote:
I have a process that fork's itself into 10 sub-processes, all of which
are very active, CPU usage is about 85%.
The system I am using has a very small L1/L2 cache that is being
trashed by the processes's working set moving in and out of cache.
I am worried about cache line conflicts. Is there anyway to instruct the
Linux virtual memory manager to spread these processes out
over physical memory so as to reduce cache line conflicts ?
Well, do please allow for a possibly more directly informed reply but
the definition of process here would seem to make the answer a simple
"no" regardless.
What you are referring to in general is cache colouring; something which
the older Linux SLAB allocator supports and the newer SLUB and SLOB
allocators do not. An inquiry as to why a while ago got answered as:
http://kerneltrap.org/mailarchive/linux-kernel/2008/8/4/2815224
which makes sense. So what's your cache organization? On something very
associative in the first place cache colouring ofcourse doesn't bring
you much.
But, regardless, with the definition here of process as "working set"
colouring seems rather unmanageable anyway.
From a narrow kernel viewpoint a process could be sort of defined as
its task_struct and colouring that one was in fact one of the original
uses of the colouring feature (the task_struct used to be 8K aligned at
stack bottom which makes for certainly non-optimized cache behaviour;
2.5 moving them of the stack then allowed for colouring) but as a
kernel, you don't allocate "a working set" as an identifiable unit; it
just sits around at whatever offset the compiler decided to put it at.
Same thing holds for dynamic allocations sort of; malloc(n) is a library
interface that doesn't (for small n) translate directly into a syscall.
So, well, just "no" it seems. And, perhaps other than in the context of
micro-optimizing a long-running calculations on a clumsy direct mapped
cache, I do believe you shouldn't really worry about it.
Rene.
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
