Re: Page host virtual assist patches.

[Hubertus Franke <frankeh@watson.ibm.com>]

Martin Schwidefsky wrote:
> On Wed, 2006-04-26 at 11:13 +1000, Nick Piggin wrote:
> 
>>OK, we'll agree to disagree for now :)
>>
>>I did start looking at the code but as you can see I only reviewed
>>patch 1 before getting sidetracked. I'll try to find some more time
>>to look at in the next few days.
> 
> 
> Thanks Nick, that would be greatly appreciated. The code is hard to
> understand, it's memory races squared. Races of the hypervisor actions
> against races in the Linux mm. Lovely. It took use quite a while to get
> that beast working, on z/VM, Linux and the millicode. 
> 

Martin, one thing that should be pointed out that despite these race
conditions, the principle concept is rather clean.
It's like putting a lock at the right place, you got to know what is
protected.

If the documentation is not clear, then lets change it.
As I see, you have not included the Documentation part into the latest
patch submission. I think doing that will help.

Kernel writers should understand when they need to make the page stable
when they should attempt to make it volatile, when the system does it for them
due to the page_cache_release.
In most cases, those functions are burried in the lower level functions already.
It just gets a bit hairy with LRU races.

Nick,  your feedback on what is not clear, would help us properly address that in
the documentation.
As for code impact, I consider this very similar to the KMAP interface.
There's not need it for 64-bit architectures, but the interface is clean and
optimized away by the compiler. The same holds true here, as Martin pointed
out there is no change in the code when disabled (one exception, not on the critical
part).

-- Hubertus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>