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.
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.
> 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 :-)
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/