On 09/04/2019 19:30, Andrew Haley wrote:
> On 4/9/19 11:42 AM, Andrew Dinn wrote:
>> This new API method was conceived as a preliminary change for JEP 352 to
>> allow selective writeback of NVRAM-backed buffers. However, it has been
>> implemented to provide a similar capability for file-mapped byte
>> buffers. The old brute-force API method, force(), continues to operate
>> as before for file-mapped byte buffers.
>>
>> One detail that is worth highlighting is that for file-backed buffers
>> the start address passed to the native method force0 is rounded down to
>> a page boundary. This is needed for Unix implementations to ensure that
>> the underlying msync system call does not throw an exception.
>
> Is it actually necessary to use a system call to do this? I would have
> thought that NVRAM allowed a finer granularity than a whole page, too.
It is necessary to use a system call to write back a normal, file-backed
buffer, whether that is for the whole buffer (original force() method)
or some subset of it (new force(int,int) method). That case is all that
the current patch is concerned with.
When NVRAM support is added the force operation will, of course, employ
a cache line writeback and will only do so for the lines that overlap
the region (i.e. it will operate at cache-line granularity rather than
file page granularity).
The prototype implementation of NVRAM support posted in earlier
discussions shows how to do that, including how to ensure that the
writeback is done using an inlined machine instruction.
regards,
Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
