> Robert M. Hyatt writes:
> > I'm certainly interested... and I agree.. the 'inc' approach is
> > great for simplicity... the 'bitmap' approach is great for
> > efficiency... And I'll certainly find time to do this and give you
> > the code...
>
> Thanks.
>
> > And I'd like to see which approach works best... but note, I want to
> > do this without the ioctl approach because that seems like a kludge.
> > A program can't set 'coloring' for itself because it is already
> > partially loaded before it gets to do that. And it would seem that
> > if the bitmap approach can be done efficiently, perhaps this can be
> > turned on for everyone.
>
> I disagree for three reasons. Firstly, it should be simple to write a
> utility that turns on page colouring and then exec()s a new
> programme. The new programme will have all of it's anonymous pages
> coloured.
>
this is the issue for me. I want _all_ pages colored... Because I
am getting 'skunked' when I have a lot of instructions, plus a modest
amount of data, and the instructions thrash cache even though it all
ought to fit.
IE I want a _complete_ solution to this problem so that _every_ page
that is allocated maps properly into cache and line usage is balanced
across the entire virtual address space of the program...
> Secondly, since the page colouring is done for anonymous pages only
> (at the moment), text pages which are read in will not be coloured. So
> even if you colour pages for all processes, the programme code won't
> be coloured. So the benefit of enabling page colouring for all
> processes is that you get to colour (probably) one extra page: the
> page used for stack variables while opening /dev/self/mem and calling
> the ioctl(). This seems like a pretty marginal improvement to me.
>
> Thirdly, I think we want to keep running without page colouring as the
> default while we're still experimenting. Let's not confuse things
> further by adding page colouring to all processes. Let's just
> selectively add it to important programmes we are benchmarking.
wouldn't disagree there at all. I was thinking both 'test-mode' and
'long-range' at the same time. Ultimately this is not something a user
ought to even know about. He just should get the best performance possible
without knowing that the cache issue even exists...
>
> > IE the time-consuming part is when the bitmap gets nearly full. We
> > might want to say 90% of the bits set is enough.. clear and start
> > over, which means we at least use 90% of cache before aliasing hits.
> > Lots of options including maybe when the cpu is going to 'halt'
> > maybe we can do something with the pt list to make this more
> > efficient. IE it might be nice to do like normal unix does for its
> > file cache, and have the 'alias bits' index into 128 pte lists,
> > where the pte's are put into the list where they belong... then we
> > can have a new pte allocator that goes right to the right list to
> > give the optimal pte... no searching, _no_ efficiency issues at all
> > there, so the ioctl might not be needed...
>
> Yes, DaveM outlined such a scheme in some private email we had. That
> would be good to try as well. Please send patches. Three algorithms to
> choose from on a per process basis :-)
>
I see it differently. Three different ways to totally blow the kernel
out of the water at first. :)
Bob
> Regards,
>
> Richard....
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/