"Jeff V. Merkey" wrote:
>
> "David S. Miller" wrote:
> >
> >Date:Tue, 10 Oct 2000 00:44:58 +0200
> >From: "Andi Kleen" <[EMAIL PROTECTED]>
> >
> >On Mon, Oct 09, 2000 at 11:41:13PM +0100, Alan Cox wrote:
> >> I dont actually know a CPU that doesnt have one in SMP mode. I
"Jeff V. Merkey" wrote:
>
> "Jeff V. Merkey" wrote:
> >
> > "David S. Miller" wrote:
> > >
> > >Date:Tue, 10 Oct 2000 00:44:58 +0200
> > >From: "Andi Kleen" <[EMAIL PROTECTED]>
> > >
> > >On Mon, Oct 09, 2000 at 11:41:13PM +0100, Alan Cox wrote:
> > >> I dont act
"David S. Miller" wrote:
>
>Date:Tue, 10 Oct 2000 00:44:58 +0200
>From: "Andi Kleen" <[EMAIL PROTECTED]>
>
>On Mon, Oct 09, 2000 at 11:41:13PM +0100, Alan Cox wrote:
>> I dont actually know a CPU that doesnt have one in SMP mode. Its just often
>> behind an I/O inte
Hello!
> > And what the hell does TCP need current for anyway?
>
> For a very hackish user context TCP implementation that probably should
> be cleaned up (but it is code freeze etc.etc.blabla.)
TCP does not _use_ value of current in softirq, certainly.
But it really refers to current, just be
In article <[EMAIL PROTECTED]>,
Jamie Lokier <[EMAIL PROTECTED]> wrote:
>Linus Torvalds wrote:
>> You can also still do the stack pointer plaything by just using
>> indirection: and when you context switch you switch the pointer around at
>> the base of the per-cpu interrupt stack.
>
>Indirection
"Jeff V. Merkey" wrote:
>
> "Jeff V. Merkey" wrote:
> >
> > "David S. Miller" wrote:
> > >
> > >Date:Tue, 10 Oct 2000 00:44:58 +0200
> > >From: "Andi Kleen" <[EMAIL PROTECTED]>
> > >
> > >On Mon, Oct 09, 2000 at 11:41:13PM +0100, Alan Cox wrote:
> > >> I dont actually kn
Based of my measurement on i386 smp configuration,
If a system has plenty of runnable tasks, schedule() produces
noticable amount of cache misses at runqueue-head traversing and the
goodness calculations.
David S. Miller writes:
> Some of us actually have instrumented it :-) I added a coloring
Date:Tue, 10 Oct 2000 10:54:11 +0100 (BST)
From: Alan Cox <[EMAIL PROTECTED]>
Having the stacks aligned also isnt good for the caches. If you are
bored some time instrument the cache lines that wake_up() touches
on a wake. Its very common to see most of them being on the sa
> Linus Torvalds wrote:
> > You can also still do the stack pointer plaything by just using
> > indirection: and when you context switch you switch the pointer around =
> at
> > the base of the per-cpu interrupt stack.
>
> Indirection, =E0 la "current =3D *(stack & ~8191)" might not be a bad ide=
Linus Torvalds wrote:
> You can also still do the stack pointer plaything by just using
> indirection: and when you context switch you switch the pointer around at
> the base of the per-cpu interrupt stack.
Indirection, à la "current = *(stack & ~8191)" might not be a bad idea
in general. As Ral
On Mon, Oct 09, 2000 at 11:30:50PM +0100, Alan Cox wrote:
> > I think I'll go for the 'current is in a well-known register'
> > approach and see how this goes...
>
> Failing that the 2.0 approach will work, current is a global in uniprocessor
> and a #define to an array indexed by cpu id in smp
On Tue, Oct 10, 2000 at 12:55:33AM +0200, Andi Kleen wrote:
> On Mon, Oct 09, 2000 at 11:45:18PM +0100, Kenn Humborg wrote:
> > Simple. Each interrupt stack is, say, 8 pages. You have an array
> > of N interrupt stacks. Then you calculate
> >
> >cpu_id = (sp & ~(INT_STACK_SIZE-1)) >> (PAGE
On Mon, Oct 09, 2000 at 11:45:18PM +0100, Kenn Humborg wrote:
> Simple. Each interrupt stack is, say, 8 pages. You have an array
> of N interrupt stacks. Then you calculate
>
>cpu_id = (sp & ~(INT_STACK_SIZE-1)) >> (PAGE_SHIFT + 3);
>
> Actually, I'd put the interrupt stack and any other
> > I dont actually know a CPU that doesnt have one in SMP mode. Its just often
> > behind an I/O interface that is slower than ideal
>
> Where would you put it for IA32 ? I don't know any free MSR that could
> be abused for that, and acessing MSRs is insanely slow anyways. Any
> other ideas ?
Date:Tue, 10 Oct 2000 00:44:58 +0200
From: "Andi Kleen" <[EMAIL PROTECTED]>
On Mon, Oct 09, 2000 at 11:41:13PM +0100, Alan Cox wrote:
> I dont actually know a CPU that doesnt have one in SMP mode. Its just often
> behind an I/O interface that is slower than ideal
Where
On Tue, Oct 10, 2000 at 12:36:35AM +0200, Andi Kleen wrote:
> On Mon, Oct 09, 2000 at 11:30:50PM +0100, Alan Cox wrote:
> > > I think I'll go for the 'current is in a well-known register'
> > > approach and see how this goes...
> >
> > Failing that the 2.0 approach will work, current is a global
On Mon, Oct 09, 2000 at 11:41:13PM +0100, Alan Cox wrote:
> > The problem is where to get the cpuid from (see how smp_processor_id
> > is currently defined ;) When you don't have a hidden register in the
> > CPU you're screwed.
> > [x86-64 has one btw]
>
> I dont actually know a CPU that doesn
> The problem is where to get the cpuid from (see how smp_processor_id
> is currently defined ;) When you don't have a hidden register in the
> CPU you're screwed.
> [x86-64 has one btw]
I dont actually know a CPU that doesnt have one in SMP mode. Its just often
behind an I/O interface that is
On Mon, 9 Oct 2000, Alan Cox wrote:
> > I think I'll go for the 'current is in a well-known register'
> > approach and see how this goes...
>
> Failing that the 2.0 approach will work, current is a global in uniprocessor
> and a #define to an array indexed by cpu id in smp
You can also still
On Mon, Oct 09, 2000 at 11:30:50PM +0100, Alan Cox wrote:
> > I think I'll go for the 'current is in a well-known register'
> > approach and see how this goes...
>
> Failing that the 2.0 approach will work, current is a global in uniprocessor
> and a #define to an array indexed by cpu id in smp
> I think I'll go for the 'current is in a well-known register'
> approach and see how this goes...
Failing that the 2.0 approach will work, current is a global in uniprocessor
and a #define to an array indexed by cpu id in smp
-
To unsubscribe from this list: send the line "unsubscribe linux-k
On Tue, Oct 10, 2000 at 09:04:30AM +1100, Keith Owens wrote:
> On 9 Oct 2000 11:08:36 -0700,
> [EMAIL PROTECTED] (Linus Torvalds) wrote:
> >Note that there are alternative approaches. For example, you could make
> >the interrupt stack be in the same multi-page as the regular stack, and
> >switch
On 9 Oct 2000 11:08:36 -0700,
[EMAIL PROTECTED] (Linus Torvalds) wrote:
>Note that there are alternative approaches. For example, you could make
>the interrupt stack be in the same multi-page as the regular stack, and
>switch them both at task-switch time - just allocate four pages instead
>of tw
On Sun, Oct 08, 2000 at 09:27:09PM +0100, Kenn Humborg wrote:
> I'm working on the VAX port and the reason I ask is that the
> VAX has separate stack pointers for user, kernel and interrupt
> contexts. Therefore, the current = (SP & ~8192) hack will give
> completely bogus results when handling
On Sun, Oct 08, 2000 at 05:05:45PM -0600, [EMAIL PROTECTED] wrote:
> > > BTW: there is an implicit reference to "current" in smp_processor_id.
> >
> > Yes, on architectures that use current->processor that is an exception
> > to the rule. After all, you know for sure that you're still on the
On Sun, Oct 08, 2000 at 04:19:01PM -0700, Mitchell Blank Jr wrote:
> Some do (look at asm-sparc/smp.h). However, linux does everything possible
> to make dereferencing "current" as fast as possible, so actually just
> looping it up there is pretty damn efficient. We need to keep track of the
>
On Sun, Oct 08, 2000 at 04:36:09PM -0600, [EMAIL PROTECTED] wrote:
> Looking at the code, I don't see any places where "current" is not valid.
> Got some examples?
More a design principle than a real problem.
> BTW: there is an implicit reference to "current" in smp_processor_id.
Which is v
In article <[EMAIL PROTECTED]>,
Kenn Humborg <[EMAIL PROTECTED]> wrote:
>
>I'd just like to confirm that it's illegal to call current()
>from interrupt-handling code.
It's not categorically forbidden.
It does indeed happen, think about things like cross-CPU interrupts for
TLB invalidations etc.
On Sun, 8 Oct 2000, Mitchell Blank Jr wrote:
> [EMAIL PROTECTED] wrote:
> > Looking at the code, I don't see any places where "current" is not valid.
> > Got some examples?
>
> It's not that its invalid, it just doesn't make much sense. It points to
> whatever task happened to be running when
On Sun, 8 Oct 2000, Kenn Humborg wrote:
>
> I'd just like to confirm that it's illegal to call current()
> from interrupt-handling code.
>
> I'm working on the VAX port and the reason I ask is that the
> VAX has separate stack pointers for user, kernel and interrupt
> contexts. Therefore, the
Hi,
> The m68k port which has a interrupt stack solves the problem by
> loading current into a global register variable on all kernel entries.
Not all m68k cpus have an interrupt stack and it can be turned off, so we
don't use it.
bye, Roman
-
To unsubscribe from this list: send the line "uns
On Mon, Oct 09, 2000 at 03:54:21AM +0200, Andi Kleen wrote:
> On Mon, Oct 09, 2000 at 02:45:54AM +0100, Kenn Humborg wrote:
> > On Mon, Oct 09, 2000 at 02:21:09AM +0100, Kenn Humborg wrote:
> > > On Mon, Oct 09, 2000 at 02:20:27AM +0200, Andi Kleen wrote:
> > > > 2.4 TCP code relies on current bei
On Mon, Oct 09, 2000 at 02:45:54AM +0100, Kenn Humborg wrote:
> On Mon, Oct 09, 2000 at 02:21:09AM +0100, Kenn Humborg wrote:
> > On Mon, Oct 09, 2000 at 02:20:27AM +0200, Andi Kleen wrote:
> > > 2.4 TCP code relies on current being valid in a softirq.
> >
> > And what the hell does TCP need curr
On Mon, Oct 09, 2000 at 02:21:09AM +0100, Kenn Humborg wrote:
> On Mon, Oct 09, 2000 at 02:20:27AM +0200, Andi Kleen wrote:
> > 2.4 TCP code relies on current being valid in a softirq.
>
> And what the hell does TCP need current for anyway?
I think the only reference is in tcp_input.c, tcp_data_
On Mon, Oct 09, 2000 at 02:21:09AM +0100, Kenn Humborg wrote:
> On Mon, Oct 09, 2000 at 02:20:27AM +0200, Andi Kleen wrote:
> > 2.4 TCP code relies on current being valid in a softirq.
>
> Well, then as long as Linux guarantees that there is always a
> valid 'current task' on a CPU, then I can s
On Mon, Oct 09, 2000 at 02:09:49AM +0100, Kenn Humborg wrote:
> > 2.4 TCP code relies on current being valid in a softirq.
> >
> > The m68k port which has a interrupt stack solves the problem by
> > loading current into a global register variable on all kernel entries.
> > x86-64 will likely do
On Mon, Oct 09, 2000 at 02:20:27AM +0200, Andi Kleen wrote:
> 2.4 TCP code relies on current being valid in a softirq.
Well, then as long as Linux guarantees that there is always a
valid 'current task' on a CPU, then I can special-case the
called-from-interrupt case. The previous kernel stack
On Mon, Oct 09, 2000 at 01:02:21AM +0200, Jamie Lokier wrote:
> [EMAIL PROTECTED] wrote:
> > BTW: there is an implicit reference to "current" in smp_processor_id.
>
> Yes I forgot about that. (Self-flagellate). However that is
> architecture specific. If it's not an SMP Vax port, no big deal
On Mon, Oct 09, 2000 at 02:20:27AM +0200, Andi Kleen wrote:
> On Mon, Oct 09, 2000 at 12:30:17AM +0200, Jamie Lokier wrote:
> > Kenn Humborg wrote:
> > > My feeling is that interrupt code has no business calling current(),
> > > but I don't know the kernel well enough to be sure. Is there any
> >
On Mon, Oct 09, 2000 at 12:30:17AM +0200, Jamie Lokier wrote:
> Kenn Humborg wrote:
> > My feeling is that interrupt code has no business calling current(),
> > but I don't know the kernel well enough to be sure. Is there any
> > interrupt-level code that calls current() or is it a design
> > pri
[EMAIL PROTECTED] wrote:
> > Yes, on architectures that use current->processor that is an exception
> > to the rule. After all, you know for sure that you're still on the
> > same CPU as the task currently running.
>
> This makes sense. And I wish cpu architects would put a cpu-id
> register som
On Mon, Oct 09, 2000 at 01:02:21AM +0200, Jamie Lokier wrote:
> [EMAIL PROTECTED] wrote:
> > Looking at the [network] code, I don't see any places where "current"
> > is not valid.
> > Got some examples?
>
> Damn I'm being dense tonight. No, that bug was due to calling "current"
> from the wron
On Sun, Oct 08, 2000 at 03:58:55PM -0700, Mitchell Blank Jr wrote:
> [EMAIL PROTECTED] wrote:
> > Looking at the code, I don't see any places where "current" is not valid.
> > Got some examples?
>
> It's not that its invalid, it just doesn't make much sense. It points to
> whatever task happene
[EMAIL PROTECTED] wrote:
> Looking at the [network] code, I don't see any places where "current"
> is not valid.
> Got some examples?
Damn I'm being dense tonight. No, that bug was due to calling "current"
from the wrong process context, not from an invalid context.
(Self-flagellate, self-flagg
[EMAIL PROTECTED] wrote:
> Looking at the code, I don't see any places where "current" is not valid.
> Got some examples?
It's not that its invalid, it just doesn't make much sense. It points to
whatever task happened to be running when the interrupt happened. So
any attempt to access it is 99
Looking at the code, I don't see any places where "current" is not valid.
Got some examples?
BTW: there is an implicit reference to "current" in smp_processor_id.
On Mon, Oct 09, 2000 at 12:30:17AM +0200, Jamie Lokier wrote:
> Kenn Humborg wrote:
> > My feeling is that interrupt code has no
Kenn Humborg wrote:
> My feeling is that interrupt code has no business calling current(),
> but I don't know the kernel well enough to be sure. Is there any
> interrupt-level code that calls current() or is it a design
> principle that it cannot be called?
It's a design principle that you must
I'd just like to confirm that it's illegal to call current()
from interrupt-handling code.
I'm working on the VAX port and the reason I ask is that the
VAX has separate stack pointers for user, kernel and interrupt
contexts. Therefore, the current = (SP & ~8192) hack will give
completely bogus
48 matches
Mail list logo
