Many thanks, I hadn't seen that. On Wed, Oct 22, 2008 at 6:09 PM, Belisko Marek <[EMAIL PROTECTED]>wrote:
> 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 >
