Mike Smith wrote:
> The basic problem here is that you have decided what "interrupt threads"
> are, and aren't interested in the fact that what FreeBSD calls "interrupt
> threads" are not the same thing, despite being told this countless times,
> and despite it being embodied in the code that's ri
> I really can't buy the idea that interrupt threads are a good
> idea for anything that can flood your bus or interrupt bandwidth,
> or have tiny/non-existant FIFOs, relative to the speeds they are
> being pushed; right now that means "might be OK for disks; not OK
> for really fast network contr
Greg Lehey wrote:
> > Solaris hits the wall a little later, but it still hits the
> > wall.
>
> Every SMP system experiences performance degradation at some point.
> The question is a matter of the extent.
IMO, 16 processors is not unreasonable, even with standard APIC
based SMP. 32 is out of t
Weiguang SHI wrote:
>
> I found an article on livelock at
>
> http://www.research.compaq.com/wrl/people/mogul/mogulpubsextern.html
>
> Just go there and search for "livelock".
>
> But I don't agree with Terry about the interrupt-thread-is-bad
> thing, because, if I read it correctly, the autho
On Wednesday, 8 August 2001 at 0:27:23 -0700, Terry Lambert wrote:
> void wrote:
>>> Can you name one SMP OS implementation that uses an
>>> "interrupt threads" approach that doesn't hit a scaling
>>> wall at 4 (or fewer) CPUs, due to heavier weight thread
>>> context switch overhead?
>>
>> Sola
their ideas in interrupt thread of the Digital Unix.
Weiguang
>From: Greg Lehey <[EMAIL PROTECTED]>
>To: Terry Lambert <[EMAIL PROTECTED]>
>CC: Bosko Milekic <[EMAIL PROTECTED]>, Matt Dillon
><[EMAIL PROTECTED]>, Zhihui Zhang <[EMAIL PROTECTED]>,
>
Mike Smith wrote:
> Terry; all this "thinking" you're doing is *really*bad*.
>
> I appreciate that you believe you're trying to "educate" us somehow. But
> what you're really doing right now is filling our list archives with
> convincing-sounding crap. People that are curious about this issue ar
> Matt Dillon wrote:
> > :What "this", exactly?
> > :
> > :That "virtual wire" mode is actually a bad idea for some
> > :applications -- specifically, high speed networking with
> > :multiple gigabit ethernet cards?
> >
> > All the cpu's don't get the interrupt, only one does.
>
> I think th
void wrote:
> > Can you name one SMP OS implementation that uses an
> > "interrupt threads" approach that doesn't hit a scaling
> > wall at 4 (or fewer) CPUs, due to heavier weight thread
> > context switch overhead?
>
> Solaris, if I remember my Vahalia book correctly (isn't that a favorite
> of
On Tuesday, 7 August 2001 at 1:58:21 -0700, Terry Lambert wrote:
> Bosko Milekic wrote:
>>> I keep wondering about the sagicity of running interrupts in
>>> threads... it still seems like an incredibly bad idea to me.
>>>
>>> I guess my major problem with this is that by running in
>>> threads,
On Tue, Aug 07, 2001 at 02:11:10AM -0700, Terry Lambert wrote:
>
> Can you name one SMP OS implementation that uses an
> "interrupt threads" approach that doesn't hit a scaling
> wall at 4 (or fewer) CPUs, due to heavier weight thread
> context switch overhead?
Solaris, if I remember my Vahalia
* Bosko Milekic <[EMAIL PROTECTED]> [010807 14:51] wrote:
>
> On Tue, Aug 07, 2001 at 12:19:01PM -0700, Matt Dillon wrote:
> > Cache line invalidation does not require an IPI. TLB
> > shootdowns require IPIs. TLB shootdowns are unrelated to
> > interrupt threads, they only occur whe
On Tue, Aug 07, 2001 at 12:19:01PM -0700, Matt Dillon wrote:
> Cache line invalidation does not require an IPI. TLB
> shootdowns require IPIs. TLB shootdowns are unrelated to
> interrupt threads, they only occur when shared mmu mappings
> change. Cache line invalidation can was
:
:Matt Dillon wrote:
:> :What "this", exactly?
:> :
:> :That "virtual wire" mode is actually a bad idea for some
:> :applications -- specifically, high speed networking with
:> :multiple gigabit ethernet cards?
:>
:> All the cpu's don't get the interrupt, only one does.
:
:I think that you
On Tue, 7 Aug 2001, Terry Lambert wrote:
> Matt Dillon wrote:
> > All the cpu's don't get the interrupt, only one does.
>
> I think that you will end up taking an IPI (Inter Processor
> Interrupt) to shoot down the cache line during an invalidate
> cycle, when moving an interrupt processing t
Zach Brown wrote:
> > That Microsoft demonstrated that wiring down interrupts
> > to a particular CPU was a good idea, and kicked both Linux'
> > and FreeBSD's butt in the test at ZD Labs?
>
> No, Terry, this is not what was demonstrated by those tests. Will this
> myth never die? Do Mike and I
Matt Dillon wrote:
> :What "this", exactly?
> :
> :That "virtual wire" mode is actually a bad idea for some
> :applications -- specifically, high speed networking with
> :multiple gigabit ethernet cards?
>
> All the cpu's don't get the interrupt, only one does.
I think that you will end up t
> That Microsoft demonstrated that wiring down interrupts
> to a particular CPU was a good idea, and kicked both Linux'
> and FreeBSD's butt in the test at ZD Labs?
No, Terry, this is not what was demonstrated by those tests. Will this
myth never die? Do Mike and I have to write up a nice white
:I'd agree that is a specialized situation, one which wouldn't
:be critical to many freebsd users. Is Terry right that the
:current strategy will "lock us into virtual wire mode", in
:some way which means that this specialized situation CANNOT
:be handled?
:
:(it would be fine if it were "handled
At 9:55 AM -0700 8/7/01, Matt Dillon wrote:
>:> > It also has the unfortunate property of locking us into virtual
>:> > wire mode, when in fact Microsoft demonstrated that wiring down
>:> > interrupts to particular CPUs was good practice, in terms of
>:> > assuring best performance. [...]
>:>
>:>
At 12:39 AM -0700 8/7/01, Mike Smith wrote:
> > It also has the unfortunate property of locking us into virtual
>> wire mode, when in fact Microsoft demonstrated that wiring down
>> interrupts to particular CPUs was good practice, in terms of
>> assuring best performance. Specifically, runnin
:> > It also has the unfortunate property of locking us into virtual
:> > wire mode, when in fact Microsoft demonstrated that wiring down
:> > interrupts to particular CPUs was good practice, in terms of
:> > assuring best performance. Specifically, running in virtual
:> > wire mode means that a
Mike Smith wrote:
>
> > It also has the unfortunate property of locking us into virtual
> > wire mode, when in fact Microsoft demonstrated that wiring down
> > interrupts to particular CPUs was good practice, in terms of
> > assuring best performance. Specifically, running in virtual
> > wire mo
Bosko Milekic wrote:
> > I keep wondering about the sagicity of running interrupts in
> > threads... it still seems like an incredibly bad idea to me.
> >
> > I guess my major problem with this is that by running in
> > threads, it's made it nearly impossibly to avoid receiver
> > livelock situati
> It also has the unfortunate property of locking us into virtual
> wire mode, when in fact Microsoft demonstrated that wiring down
> interrupts to particular CPUs was good practice, in terms of
> assuring best performance. Specifically, running in virtual
> wire mode means that all your CPUs get
* Bosko Milekic <[EMAIL PROTECTED]> [010807 02:16] wrote:
>
> On Mon, Aug 06, 2001 at 11:27:56PM -0700, Terry Lambert wrote:
> > I keep wondering about the sagicity of running interrupts in
> > threads... it still seems like an incredibly bad idea to me.
> >
> > I guess my major problem with thi
On Mon, Aug 06, 2001 at 11:27:56PM -0700, Terry Lambert wrote:
> I keep wondering about the sagicity of running interrupts in
> threads... it still seems like an incredibly bad idea to me.
>
> I guess my major problem with this is that by running in
> threads, it's made it nearly impossibly to a
Matt Dillon wrote:
> Yes, that is precisely the reason. In -current this all changes, though,
> since interrupts are now threads. *But*, that said, interrupts cannot
> really afford to hold mutexes that might end up blocking them for
> long periods of time so I would still recomm
:I should have guessed the reason. Matthew Dillon answered this question on
:Fri, 2 Jun 2000 as follows:
:
:
:The VM routines that manage pages associated with objects are not
:protected against interrupts, so interrupts aren't allowed to change
:page-object associations. Otherwi
FreeBSD can not allocate from the PQ_CACHE queue in an interrupt context.
Can anyone explain it to me why this is the case?
Thanks,
-Zhihui
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
FreeBSD can not allocate from the PQ_CACHE queue in an interrupt
context. Can anyone explain it to me why this is the case?
Thanks,
-Zhihui
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
31 matches
Mail list logo
