On 8/2/23 08:27, Jeff Moyer wrote: > Christoph Hellwig <hch@xxxxxx> writes: > >> Given that pmem simply loops over an arbitrarily large bio I think >> we also need a threshold for which to allow nowait I/O. While it >> won't block for giant I/Os, doing all of them in the submitter >> context isn't exactly the idea behind the nowait I/O. >> >> I'm not really sure what a good theshold would be, though. > There's no mention of the latency of the submission side in the > documentation for RWF_NOWAIT. The man page says "Do not wait for data > which is not immediately available." Data in pmem *is* immediately > available. If we wanted to enforce a latency threshold for submission, > it would have to be configurable and, ideally, a part of the API. I > don't think it's something we should even try to guarantee, though, > unless application writers are asking for it. I need to see the usecase from application writter who cannot come with a solution so kernel have to provide this interface, I'll be happy to do that .. > So, I think with the change to return -EAGAIN for writes to poisoned > memory, this patch is probably ok. I believe you mean the same one I've provided earlier incremental .. > Chaitanya, could you send a v2? sure ... -ck
