These is an excellent atricle "What every programmer should about memory " of Erlich dreeper. you will see what happens when you exceed L2,L1... On Wed, Oct 22, 2008 at 1:54 PM, Rene Herman <rene.herman@xxxxxxxxxxxx> wrote: > 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 > > -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
