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škoRuská Nová Ves 21908005 PrešovSlovakiahttp://binaural.ifastnet.com��.n��������+%����w�j)p���{.n����z�ޖw�n'���q���b�������v��m�����Y�����
