Yes, great article can be found at: http://lwn.net/Articles/250967/
Thanks Marek On Wed, Oct 22, 2008 at 6:57 PM, Raz <[EMAIL PROTECTED]> wrote: > 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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] >> Please read the FAQ at http://kernelnewbies.org/FAQ >> >> > > -- > To unsubscribe from this list: send an email with > "unsubscribe kernelnewbies" to [EMAIL PROTECTED] > Please read the FAQ at http://kernelnewbies.org/FAQ > > -- as simple as primitive as possible ---------------------------------------------- Marek Beliško Ruská Nová Ves 219 08005 Prešov Slovakia http://binaural.ifastnet.com
