netdev - Re: [PATCH 2/6] pkt_sched: sch_htb: Consider used jiffies in htb

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]

Date:	Tue, 9 Dec 2008 11:32:05 +0000
From:	Jarek Poplawski <jarkao2@...il.com>
To:	Patrick McHardy <kaber@...sh.net>
Cc:	David Miller <davem@...emloft.net>, Martin Devera <devik@....cz>,
	netdev@...r.kernel.org
Subject: Re: [PATCH 2/6] pkt_sched: sch_htb: Consider used jiffies in
	htb_dequeue()

On Tue, Dec 09, 2008 at 11:28:44AM +0100, Patrick McHardy wrote:
> Jarek Poplawski wrote:
>> Next event time should consider jiffies used for recounting. Otherwise
>> qdisc_watchdog_schedule() triggers hrtimer immediately with the event
>> in the past, and may cause very high ksoftirqd cpu usage (if highres
>> is on). This patch charges jiffies globally, so we can skip this in
>> htb_do_events().
>>
>> Signed-off-by: Jarek Poplawski <jarkao2@...il.com>
>> ---
>>  net/sched/sch_htb.c |   14 ++++++++++++--
>>  1 files changed, 12 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/sched/sch_htb.c b/net/sched/sch_htb.c
>> index d6eb4a7..102866d 100644
>> --- a/net/sched/sch_htb.c
>> +++ b/net/sched/sch_htb.c
>> @@ -685,8 +685,11 @@ static psched_time_t htb_do_events(struct htb_sched *q, int level)
>>  		if (cl->cmode != HTB_CAN_SEND)
>>  			htb_add_to_wait_tree(q, cl, diff);
>>  	}
>> -	/* too much load - let's continue on next jiffie (including above) */
>> -	return q->now + 2 * PSCHED_TICKS_PER_SEC / HZ;
>> +	/*
>> +	 * Too much load - let's continue on next jiffie.
>> +	 * (Used jiffies are charged later.)
>> +	 */
>> +	return q->now + 1;
>>  
>
> This (including the last patch) is really confusing - q->now doesn't
> contain HZ values but psched ticks. Could you describe the overall
> algorithm you're trying to implement please?

The algorithm is we want to "continue on the next jiffie". We know
we've lost here a lot of time (~2 jiffies), and this will be added
later. Since these jiffies are not precise enough wrt. psched ticks
or ktime, and we will add around 2000 (for HZ 1000) psched ticks
anyway this +1 here simply doesn't matter and can mean "a bit after
q->now".

We can try to do this more precisely with additional psched_get_time(),
instead of jiffies, but my "tests" didn't show any advantage. What
matters is to avoid longer scheduling with the past time.

This case can probably happen only with very low rate limits for a
large number of classes, and I guess they simply need some spare time,
not necessarily at psched tick precision.

Jarek P.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html