From: Jarek Poplawski <jarkao2@gmail.com>
To: Patrick McHardy <kaber@trash.net>
Cc: David Miller <davem@davemloft.net>, Martin Devera <devik@cdi.cz>,
netdev@vger.kernel.org
Subject: [PATCH 8/6] Re: [PATCH 2/6] pkt_sched: sch_htb: Consider used jiffies in htb_dequeue()
Date: Wed, 10 Dec 2008 10:52:53 +0000 [thread overview]
Message-ID: <20081210105253.GA9344@ff.dom.local> (raw)
In-Reply-To: <493E8709.5070601@trash.net>
On Tue, Dec 09, 2008 at 03:56:09PM +0100, Patrick McHardy wrote:
...
> I meant "at all" for the wakeup after we've decided HTB has too much
> work to do at once. A work queue seems better suited since that makes
> sure we allow other processes to run, but don't wait unnecessarily
> long when there is no other work.
Maybe I miss your point, but IMHO the too much work case isn't a
problem here: there is a lot of time wasted in this case, so e.g.
additional psched_get_time() and "safe" rescheduling is possible -
no need to complicate it with workqueues etc. (but current patch 7
should be enough). I'm concerned with e.g. a config doing often
htb_do_events() and htb_dequeue_tree() in ~1 jiffie and
rescheduling for 1/2 jiffie (or 1/2 vs. 1/4 etc.), so mainly in
the past. hrtimers beahave with this really different from timers.
>>> Jiffies might wrap even if it only took only a few nanoseconds.
>>> And its not fine, in the case of throttled classes there's no
>>> reason to add extra delay *at all*.
>>
>> Yes, you are right with this. I can try too fix this tomorrow, unless
>> you prefer to send your version of this patch.
>
> I don't have a version of my own, so please go ahead :)
Alas I haven't found how we can fix it generally without any such costs,
so I think I've to leave this problem for now. Then only this "over 2
jiffies" case should be fixed here (current patch 7), plus I propose the
patch below to additionally skip doing events generally after 2 jiffies.
Thanks,
Jarek P.
-------------> (redone old patch 3 - to apply on top of patch 7)
pkt_sched: sch_htb: Break all htb_do_events() after 2 jiffies
Currently htb_do_events() breaks events recounting for a level after 2
jiffies, but there is no reason to repeat this for next levels and
increase delays even more (with softirqs disabled). htb_dequeue_tree()
can add to this too, btw. In such a case q->now time is invalid anyway.
Thanks to Patrick McHardy for spotting an error around earlier version
of this patch.
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
---
net/sched/sch_htb.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/sched/sch_htb.c b/net/sched/sch_htb.c
index 9ca8a26..2f0f0b0 100644
--- a/net/sched/sch_htb.c
+++ b/net/sched/sch_htb.c
@@ -661,12 +661,13 @@ static void htb_charge_class(struct htb_sched *q, struct htb_class *cl,
* next pending event (0 for no event in pq).
* Note: Applied are events whose have cl->pq_key <= q->now.
*/
-static psched_time_t htb_do_events(struct htb_sched *q, int level)
+static psched_time_t htb_do_events(struct htb_sched *q, int level,
+ unsigned long start)
{
/* don't run for longer than 2 jiffies; 2 is used instead of
1 to simplify things when jiffy is going to be incremented
too soon */
- unsigned long stop_at = jiffies + 2;
+ unsigned long stop_at = start + 2;
while (time_before(jiffies, stop_at)) {
struct htb_class *cl;
long diff;
@@ -845,6 +846,7 @@ static struct sk_buff *htb_dequeue(struct Qdisc *sch)
struct htb_sched *q = qdisc_priv(sch);
int level;
psched_time_t next_event;
+ unsigned long start_at;
/* try to dequeue direct packets as high prio (!) to minimize cpu work */
skb = __skb_dequeue(&q->direct_queue);
@@ -857,6 +859,7 @@ static struct sk_buff *htb_dequeue(struct Qdisc *sch)
if (!sch->q.qlen)
goto fin;
q->now = psched_get_time();
+ start_at = jiffies;
next_event = q->now + 5 * PSCHED_TICKS_PER_SEC;
@@ -866,7 +869,7 @@ static struct sk_buff *htb_dequeue(struct Qdisc *sch)
psched_time_t event;
if (q->now >= q->near_ev_cache[level]) {
- event = htb_do_events(q, level);
+ event = htb_do_events(q, level, start_at);
if (!event)
event = q->now + PSCHED_TICKS_PER_SEC;
q->near_ev_cache[level] = event;
next prev parent reply other threads:[~2008-12-10 10:53 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-09 10:21 [PATCH 2/6] pkt_sched: sch_htb: Consider used jiffies in htb_dequeue() Jarek Poplawski
2008-12-09 10:28 ` Patrick McHardy
2008-12-09 11:32 ` Jarek Poplawski
2008-12-09 12:25 ` Patrick McHardy
2008-12-09 13:08 ` Jarek Poplawski
2008-12-09 13:20 ` Patrick McHardy
2008-12-09 14:45 ` Jarek Poplawski
2008-12-09 14:56 ` Patrick McHardy
2008-12-10 10:52 ` Jarek Poplawski [this message]
2009-01-12 10:17 ` [PATCH 8/6 resend] pkt_sched: sch_htb: Break all htb_do_events() after 2 jiffies Jarek Poplawski
2009-01-13 5:54 ` David Miller
2008-12-10 6:35 ` [PATCH 2/6] pkt_sched: sch_htb: Consider used jiffies in htb_dequeue() David Miller
2008-12-10 9:11 ` Jarek Poplawski
2008-12-10 9:14 ` David Miller
2008-12-10 9:35 ` [PATCH 7/6] " Jarek Poplawski
2008-12-10 14:38 ` Patrick McHardy
2008-12-16 23:57 ` David Miller
2008-12-17 7:03 ` Jarek Poplawski
2008-12-17 7:38 ` David Miller
2009-01-12 6:56 ` Patrick McHardy
2009-01-12 10:10 ` Jarek Poplawski
2009-01-12 10:22 ` Patrick McHardy
2009-01-12 11:08 ` Jarek Poplawski
2009-01-12 13:10 ` Patrick McHardy
2009-01-28 12:52 ` [PATCH net-next] pkt_sched: sch_htb: Warn on too many events Jarek Poplawski
2009-01-28 16:18 ` Patrick McHardy
2009-01-30 10:17 ` [PATCH 1/3 v2 " Jarek Poplawski
2009-02-01 9:13 ` David Miller
2009-01-30 10:17 ` [PATCH 2/3 " Jarek Poplawski
2009-02-01 9:13 ` David Miller
2009-01-30 10:17 ` [PATCH 3/3 " Jarek Poplawski
2009-02-01 9:13 ` David Miller
2009-01-28 13:23 ` [PATCH 7/6] Re: [PATCH 2/6] pkt_sched: sch_htb: Consider used jiffies in htb_dequeue() Jarek Poplawski
2009-01-28 16:20 ` Patrick McHardy
2009-01-12 10:29 ` Jarek Poplawski
2009-01-12 10:32 ` David Miller
2009-01-12 10:59 ` Jarek Poplawski
2009-01-12 11:04 ` David Miller
2009-01-12 10:16 ` [PATCH 7/6 resend] pkt_sched: sch_htb: Consider used jiffies in htb_do_events() Jarek Poplawski
2009-01-13 5:54 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081210105253.GA9344@ff.dom.local \
--to=jarkao2@gmail.com \
--cc=davem@davemloft.net \
--cc=devik@cdi.cz \
--cc=kaber@trash.net \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).