On Wed, Oct 22, 2008 at 6:09 PM, Belisko Marek <marek.belisko@xxxxxxxxx> 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 <raziebe@xxxxxxxxx> 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 <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
>
>
as simple as primitive as possible
----------------------------------------------
Marek Beliško
Ruská Nová Ves 219
08005 Prešov
Slovakia
http://binaural.ifastnet.com
