linux-kernel - Re: [PATCH] SUNRPC: restore fair scheduling to priority queues.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 10 Feb 2016 12:45:37 +1100
From:	NeilBrown <neilb@...e.com>
To:	Trond Myklebust <trond.myklebust@...marydata.com>
Cc:	Anna Schumaker <anna.schumaker@...app.com>,
	Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] SUNRPC: restore fair scheduling to priority queues.

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@...e.com> 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

Download attachment "signature.asc" of type "application/pgp-signature" (819 bytes)