Messages in this thread | | | Date | Sat, 30 Jan 1999 19:10:11 -0600 (CST) | From | "Robert M. Hyatt" <> | Subject | Re: your mail |
| |
On Sun, 31 Jan 1999, Richard Gooch wrote:
> 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/
| |