[ forgive formatting, a series of unfortunate events has me using Outlook for 
the moment ]

> From: Jan Kara <j...@suse.cz>
> > > > These flags are device properties that affect the kernel and
> > > > userspace's handling of persistence.
> > > >
> > >
> > > That will not handle the scenario with multiple applications using
> > > the same fsdax mount point where one is updated to use the new
> > > instruction and the other is not.
> >
> > Right, it needs to be a global setting / flag day to switch from one
> > regime to another. Per-process control is a recipe for disaster.
> 
> First I'd like to mention that hopefully the concern is mostly theoretical 
> since
> as Aneesh wrote above, real persistent memory never shipped for PPC and
> so there are very few apps (if any) using the old way to ensure cache
> flushing.
> 
> But I'd like to understand why do you think per-process control is a recipe 
> for
> disaster? Because from my POV the sysfs interface you propose is actually
> difficult to use in practice. As a distributor, you have hard time picking the
> default because you have a choice between picking safe option which is
> going to confuse users because of failing MAP_SYNC and unsafe option
> where everyone will be happy until someone looses data because of some
> ancient application using wrong instructions to persist data. Poor experience
> for users in either way. And when distro defaults to "safe option", then the
> burden is on the sysadmin to toggle the switch but how is he supposed to
> decide when that is safe? First he has to understand what the problem
> actually is, then he has to audit all the applications using pmem whether they
> use the new instruction - which is IMO a lot of effort if you have a couple of
> applications and practically infeasible if you have more of them.
> So IMO the burden should be *on the application* to declare that it is aware
> of the new instructions to flush pmem on the platform and only to such
> application the kernel should give the trust to use MAP_SYNC mappings.

The "disaster" in my mind is this need to globally change the ABI for 
persistence semantics for all of Linux because one CPU wants a do over. What 
does a generic "MAP_SYNC_ENABLE" knob even mean to the existing deployed base 
of persistent memory applications? Yes, sysfs is awkward, but it's trying to 
provide some relief without imposing unexplainable semantics on everyone else. 
I think a comprehensive (overengineered) solution would involve not introducing 
another "I know what I'm doing" flag to the interface, but maybe requiring 
applications to call a pmem sync API in something like a vsyscall. Or, also 
overengineered, some binary translation / interpretation to actively detect and 
kill applications that deploy the old instructions. Something horrid like on 
first write fault to a MAP_SYNC try to look ahead in the binary for the correct 
sync sequence and kill the application otherwise. That would at least provide 
some enforcement and safety without requiring other architectures to consider 
what MAP_SYNC_ENABLE means to them.

Reply via email to