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: <20090420061602.GO4593@kernel.dk>
Date:	Mon, 20 Apr 2009 08:16:02 +0200
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Carl Henrik Lunde <chlunde@...g.uio.no>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: CFQ: Preemption/timeout logic reversed?

On Mon, Apr 20 2009, Carl Henrik Lunde wrote:
> Hi!
> 
> It seems the preemption "bonus" logic in CFQ is reversed, a preempted
> process is given an additional delay in start time instead of a bonus.
>  This seems unfair.  I'm not sure if it's a good idea to let

Hmm? ->slice_resid is a long, so if we preempt the process 10 jiffies
before it was supposed to end, the resid will be -10. So it'll not
increase the rb_key, it'll decrease it.

> slice_resid grow without limit as shown below, but isn't this more
> like the way it was intended to work?  Or did I misunderstand
> something?

->slice_resid is reset when it gets repositioned in the rb tree. The
intent was not to increase the slice length, but instead allow it sooner
service again.

> PS! The comment above cfq_preempt_queue seems outdated too.

Yep, the slice length comment is out dated indeed.

> Code not tested, just showing what I mean:
> 
> diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
> index 664ebfd..ea18d45 100644
> --- a/block/cfq-iosched.c
> +++ b/block/cfq-iosched.c
> @@ -292,7 +292,8 @@ cfq_prio_to_slice(struct cfq_data *cfqd, struct
> cfq_queue *cfqq)
>  static inline void
>  cfq_set_prio_slice(struct cfq_data *cfqd, struct cfq_queue *cfqq)
>  {
> -       cfqq->slice_end = cfq_prio_to_slice(cfqd, cfqq) + jiffies;
> +       cfqq->slice_end = cfq_prio_to_slice(cfqd, cfqq) +
> cfqq->slice_resid + jiffies;

So if ->slice_resid is negative because we preempted this queue, it'll
now get a shorter slice. That's not very nice :-)

-- 
Jens Axboe

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ