Re: [RFC][PATCH 1/3] tracking dirty pages in shared mappings -V4

[Brian Twichell <tbrian@us.ibm.com>]

Martin Bligh wrote:

> Peter Chubb wrote:
>
>>
>> What does this do to performance on TPC workloads?  How many extra
>> faults are there likely to be?
>
>
> They all use large pages anyway ...
>
> M.
>
That much is true, but let me make sure I understand how this will 
impact customer transaction-processing workloads, where hugepages are 
infrequently used.

Under the proposed scheme, when the database starts up, it will take a 
write fault when it initializes a shared memory page, and the page will 
be marked as dirty.  Then, as long as the page is never swapped out, the 
write protection will never be "re-armed".

Since customers usually tune their databases to never swap, then the 
only potential additional cost I would envision would be the small cost 
of initially marking the page as write-protected, and marking the page 
as dirty during the first fault. 

Does this sound reasonable ?

Cheers,
Brian


--
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>