linux-kernel - Re: [PATCH 1/1] CFQ: fix handling 'deep' cfqq

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+X1aCSMb9CTpoHWv=UiMg-mHkB2ssmKRACtbDofWG=QSxXOdg@mail.gmail.com>
Date:	Wed, 31 Aug 2011 13:12:02 +0400
From:	Maxim Patlasov <maxim.patlasov@...il.com>
To:	Shaohua Li <shli@...nel.org>
Cc:	axboe@...nel.dk, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] CFQ: fix handling 'deep' cfqq

Shaohua,

Sorry for not getting back to you for long. See please inline comments below.

> but the cfq_disk_looks_slow isn't updated if the queue doesn't have 4 requests
> or doesn't dispatch > 4 requests, so you always have CFQD_DISK_LOOKS_FAST()
> return true if the first slice gets it to true. And if the queue does
> dispatch > 4 requests in one jiffy, only cfq_disk_looks_fast is updated,
> CFQD_DISK_LOOKS_FAST returns true too. I don't understand when
> CFQD_DISK_LOOKS_FAST can be false.

The patch essentially gathers events when cfqq experiences deep queue
early and dispatches 4 requests in one dispatch round. As soon as such
an event detected, we're drop inside outer 'if' clause:

> +	if (cfq_cfqq_deep_early(cfqq) && cfqq->n_dispatched >= CFQQ_DEEP_THR) {
> +		if (cfqq->first_dispatch == jiffies)
> +			cfqd->cfq_disk_looks_fast++;
> +		else
> +			cfqd->cfq_disk_looks_slow++;
> +
> +		cfqq->first_dispatch = 0;
> +		cfqq->n_dispatched = 0;
> +		cfq_clear_cfqq_deep_early(cfqq);
> +		cfqd->cfq_disk_last_updated = jiffies;
> +	}

and either increment disk_looks_fast or disk_looks_slow.

If the queue doesn't have 4 requests, cfqq is not 'deep' - no events
to gather. Neither disk_looks_fast nor disk_looks_slow is updated.

If the queue doesn't dispatch 4 requests in a raw, the event will be
discarded, and again, neither disk_looks_fast nor disk_looks_slow is
updated.

If the queue does dispatch > 4 requests in one jiffy, only
cfq_disk_looks_fast is updated - that's right. But if the queue
dispatches first 4 requests in *more* than one jiffy,
cfq_disk_looks_slow is updated.

BTW, note that CFQD_DISK_LOOKS_FAST returns true only if
disk_looks_fast greater than disk_looks_slow. So, in case of rare
accidental events, disk_looks_fast/slow counters will expire soon and
CFQD_DISK_LOOKS_FAST will return false ("0 > 0").

Thanks,
Maxim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/