[lkml]   [2000]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: PATCH: 8139too kernel thread
Linus Torvalds wrote:
> But yes, on 2.4.x the cost of threads is fairly low. The biggest cost by
> far is probably the locking needed for the scheduler etc, and there the
> best rule of thumb is probably to see whether the driver really ends up
> being noticeably simpler.

My main motivations for moving media selection from a timer into a
kernel thread are:
* the timer oftens takes a loooong time to run (some drivers have extra
junk in the timer funcs that really should be in a kthread anyway), and
* do_ioctl, which calls the mdio_xxx functions, holds rtnl_lock, which
is a semaphore. the kernel thread can easily acquire this semaphore
too, a timer can't.

I agree that it needs to be examined on a case-by-case basis. Better
hardware, where MDIO access is just a few bus reads/writes, probably
doesn't need a kernel thread.

Finally, for most net drivers, media selection occurs once every 60
seconds or so, not a big impact even on 2.2.x...

> The event stuff that we are discussing for pcmcia may make all of this
> moot, maybe media selection is the perfect example of how to do the very
> same thing. I'll forward Jeff the emails on that.

I think I'm already on the CC list.

I'm confused here though.... How does tq_context apply here? Your
suggested direction of tq_context seems ok, but I don't see how it
applies to situations where polling needs to occur, like where yenta
polls when request_irq fails, or when net drivers poll media selection



Jeff Garzik |
Building 1024 | The chief enemy of creativity is "good" sense
MandrakeSoft | -- Picasso
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:24    [W:0.181 / U:3.536 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site