All of lore.kernel.org
 help / color / mirror / Atom feed
From: george anzinger <george@mvista.com>
To: kuznet@ms2.inr.ac.ru
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Replace timer_bh with tasklet
Date: Wed, 19 Jun 2002 17:39:59 -0700	[thread overview]
Message-ID: <3D11245F.DB13A07C@mvista.com> (raw)
In-Reply-To: 200206181829.WAA13590@sex.inr.ac.ru

kuznet@ms2.inr.ac.ru wrote:
> 
> Hello!
> 
> > > But this is impossible, timers must not race with another BHs,
> > > all the code using BHs depends on this. That's why they are BHs.
> >
> > If indeed they do "race" the old code had the timer_bh being first.
> > So does this patch.
> 
> I do not understand what you mean here.
> 
> I feel you misunderstand my comment. I said the patch is one pure big bug,
> because tasklets are not serialized wrt BHs. Timer MUST. If you are going
> to get rid of this must, start from editing all the code which makes this
> assumption.

At this point I am only aware of one place in the kernel where timers and 
other BH code interact, that being deliver_to_old_ones() in net/core/dev.c.
Even there, it appears that the interaction is not with another BH but with
code that at one time was BH code.  As I understand it, BH and all of its
support stuff is being removed from the kernel.  That is why I was asked to
submit this patch.  So far, this is the only area that has come up as a 
locking or serialization problem.

As to this bit of code, it appears that changing it to do much the same as 
it did to the timer_bh to the new timer softirq should resolve the issue.

If you have additional input on this or other problems that need to be addressed,
I welcome it.

Correct me if I am wrong, but it looks like the network code has already left
the BH playing field.
> 
~snip
> 
> > Not really.  One REALLY expects timers to expire in timed order :)  Using
> > a separate procedure to deliver a timer just because it is of a different
> > resolution opens one up to a world of pathology.
> 
> Are you going to mix use of hires and lores timers for one task?  

Of course.  Why use high-res when you don't need it?  There is additional
overhead for high-res.  To require all timers to be high-res when only one
is needed is a waste.

-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Real time sched:  http://sourceforge.net/projects/rtsched/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

  reply	other threads:[~2002-06-20  0:40 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-18  3:45 [PATCH] Replace timer_bh with tasklet george anzinger
2002-06-18  4:06 ` Linus Torvalds
2002-06-18 18:07   ` george anzinger
2002-06-18 22:46     ` Richard Zidlicky
2002-06-18 23:17       ` george anzinger
2002-06-19 11:43         ` Richard Zidlicky
2002-06-18  4:15 ` David S. Miller
2002-06-18 17:01   ` george anzinger
2002-06-18 17:12     ` Matthew Wilcox
2002-06-18 18:14   ` george anzinger
2002-06-18  5:16 ` kuznet
2002-06-18 18:19   ` george anzinger
2002-06-18 18:29     ` kuznet
2002-06-20  0:39       ` george anzinger [this message]
2002-06-20  1:34         ` David S. Miller
2002-06-20  1:53           ` Robert Love
2002-06-20  1:55             ` David S. Miller
2002-06-20  2:05               ` Robert Love
2002-06-20  2:01                 ` David S. Miller
2002-06-20  2:15                   ` Robert Love
2002-06-20  2:23                     ` David S. Miller
2002-06-20 23:54                       ` george anzinger
2002-06-21  1:03                         ` David S. Miller
2002-06-21 14:04                           ` george anzinger
2002-06-21 14:08                             ` David S. Miller
2002-06-20  8:11               ` Russell King
2002-06-20  8:09                 ` David S. Miller
2002-06-20  8:16                   ` Russell King
2002-06-20  8:13               ` Russell King
2002-06-20 14:33             ` kuznet

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=3D11245F.DB13A07C@mvista.com \
    --to=george@mvista.com \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=linux-kernel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.