Brian King <brking@xxxxxxxxxxxxxxxxxx> writes: > On 02/13/2017 08:04 PM, Benjamin Herrenschmidt wrote: >> On Mon, 2017-02-13 at 15:57 -0600, Brian King wrote: >>> If we do transition to use remove rather than shutdown, I think we >>> want >>> some way for a device driver to know whether we are doing kexec or >>> not. >>> A RAID adapter with a write cache is going to want to flush its write >>> cache on a PCI hotplug remove, but for a kexec, its going to want to >>> skip >>> that so the kexec is faster. Today, since kexec looks like a reboot, >>> rather than a shutdown, we can skip the flush on a reboot, since its >>> technically not needed there either. >> >> What happens if a non-flushed adapter gets a PERST ? > > It depends on the adapter, so it really needs to be a policy in the device > driver. For any adapter that has a non volatile write cache, data must preserved, > otherwise the write cache is not truly non volatile. For adapters with a volatile > write cache, then its subject to the adapter hardware. For ipr adapters > that have a volatile cache, they do guarantee the data is preserved across > a PERST. > >> I wouldn't trust that 'don't have to flush' magic ... > > I really don't think we want to force RAID adapters that have gigabytes of > *non volatile* write cache to flush their cache when we are merely performing > a kexec. This can take several minutes in the worst case scenarios. It is very very simple. kexec does not guarantee what comes after it. An optimization that skips flushing because the hardware write cache can be trusted is fine. An optimization that skips flushing because some later kernel will take care of it is not. I really don't see any room in there for distinguishing between which kind of shutdown and/or kexec we are doing. Either the hardware handles it or it doesn't. If the hardware doesn't handle everything than we need to handle it in software. Eric
