On Wed, Feb 10 2016, NeilBrown wrote:
> On Sun, Dec 27 2015, Trond Myklebust wrote:
>
>> On Tue, Dec 15, 2015 at 10:10 PM, NeilBrown <neilb@xxxxxxxx> wrote:
>>> If you treated all reads and writed the same, then I can't see value in
>>> restoring fair scheduling. If there is any difference, then I suspect
>>> we do need the fairness.
>>
>> I disagree. Reclaiming memory should always be able to pre-empt
>> "interactive" features such as read. Everything goes down the toilet
>> when we force the kernel into situations where it needs to swap.
>
> That's your call I guess. I certainly agree that memory-reclaim writes
> should get some priority (e.g. two writes serviced for every read).
> Whether they should be allowed to completely block reads I'm less sure
> of. But it is probably purely academic as if the system is busy
> reclaiming you are unlikely to have any reads to want to send.
>
> My problem would be solved (I think) by treating reads and non-reclaim
> writes as equals. I'll make a patch, see if I can test it, and let you
> know.
ahh.... I just discovered
Commit: b0ac1bd2bbfd ("NFS: Background flush should not be low priority")
I didn't notice that before. I suspect that will fix the problem -
thanks.
I'll try testing and let you know if there is a problem.
Thanks,
NeilBrown
Attachment:
signature.asc
Description: PGP signature
