> On Thursday 16 August 2007 01:39, Satyam Sharma wrote:
> >
> > static inline void wait_for_init_deassert(atomic_t *deassert)
> > {
> > - while (!atomic_read(deassert));
> > + while (!atomic_read(deassert))
> > + cpu_relax();
> > return;
> > }
>
> For less-than-briliant
On Thursday 16 August 2007 01:39, Satyam Sharma wrote:
static inline void wait_for_init_deassert(atomic_t *deassert)
{
- while (!atomic_read(deassert));
+ while (!atomic_read(deassert))
+ cpu_relax();
return;
}
For less-than-briliant people like me, it's
On Sun, May 20, 2001 at 05:24:48PM +0100, Dave Airlie wrote:
>
> I'm implementing start_thread for the VAX port and am wondering does
> start_thread have to return to load_elf_binary? I'm working on the init
> thread and what is happening is it is returning the whole way back to the
> execve
Quick question...
Back in 2.2, we could use DHCP to auto-config the IP setup. In fact,
the choice was DHCP, BOOTP or RARP.
Now there is only BOOTP or RARP. What happened to DHCP support?
Later,
Kenn
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Quick question...
Back in 2.2, we could use DHCP to auto-config the IP setup. In fact,
the choice was DHCP, BOOTP or RARP.
Now there is only BOOTP or RARP. What happened to DHCP support?
Later,
Kenn
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Mon, Mar 05, 2001 at 04:15:36PM -0800, H. Peter Anvin wrote:
> > So, to summarise (for 32-bit CPUs):
> >
> > o Alan Cox & Manfred Spraul say 4-byte alignment is guaranteed.
> >
> > o If you need larger alignment, you need to alloc a larger space,
> >round as necessary, and keep the
On Sun, Mar 04, 2001 at 11:41:12PM +0100, Manfred Spraul wrote:
> >
> > Does kmalloc() make any guarantees of the alignment of allocated
> > blocks? Will the returned block always be 4-, 8- or 16-byte
> > aligned, for example?
> >
>
> 4-byte alignment is guaranteed on 32-bit cpus, 8-byte
On Sun, Mar 04, 2001 at 11:41:12PM +0100, Manfred Spraul wrote:
Does kmalloc() make any guarantees of the alignment of allocated
blocks? Will the returned block always be 4-, 8- or 16-byte
aligned, for example?
4-byte alignment is guaranteed on 32-bit cpus, 8-byte alignment on
On Mon, Mar 05, 2001 at 04:15:36PM -0800, H. Peter Anvin wrote:
So, to summarise (for 32-bit CPUs):
o Alan Cox Manfred Spraul say 4-byte alignment is guaranteed.
o If you need larger alignment, you need to alloc a larger space,
round as necessary, and keep the original pointer
Does kmalloc() make any guarantees of the alignment of allocated
blocks? Will the returned block always be 4-, 8- or 16-byte
aligned, for example?
Later,
Kenn
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
Does kmalloc() make any guarantees of the alignment of allocated
blocks? Will the returned block always be 4-, 8- or 16-byte
aligned, for example?
Later,
Kenn
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
On Sun, Feb 18, 2001 at 10:53:16PM +, Russell King wrote:
> Kenn Humborg writes:
> > When starting bdflush and kupdated, bdflush_init() uses a semaphore to
> > make sure that the threads have run before continuing. Shouldn't
> > start_context_thread() do something
On Sun, Feb 18, 2001 at 10:53:16PM +, Russell King wrote:
Kenn Humborg writes:
When starting bdflush and kupdated, bdflush_init() uses a semaphore to
make sure that the threads have run before continuing. Shouldn't
start_context_thread() do something similar?
I think this would
In init/main.c, do_basic_setup() we have:
start_context_thread();
do_initcalls();
start_context_thread() calls kernel_thread() to start the keventd
thread. Then do_initcalls() calls all the init functions and
finishes by calling flush_scheduled_tasks(). This function ends
up
In init/main.c, do_basic_setup() we have:
start_context_thread();
do_initcalls();
start_context_thread() calls kernel_thread() to start the keventd
thread. Then do_initcalls() calls all the init functions and
finishes by calling flush_scheduled_tasks(). This function ends
up
On Mon, Oct 30, 2000 at 07:15:58PM +, I wrote:
>
> Can anyone point me to an explanation of the third arg to
> switch_to(prev, next, last)?
>
> It appeared in 2.2.8.
>
> What exactly is supposed to be written to it?
Mea culpa...
Further digging revealed that it's for returning prev in
Can anyone point me to an explanation of the third arg to
switch_to(prev, next, last)?
It appeared in 2.2.8.
What exactly is supposed to be written to it?
Thanks,
Kenn
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Can anyone point me to an explanation of the third arg to
switch_to(prev, next, last)?
It appeared in 2.2.8.
What exactly is supposed to be written to it?
Thanks,
Kenn
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
On Mon, Oct 30, 2000 at 07:15:58PM +, I wrote:
Can anyone point me to an explanation of the third arg to
switch_to(prev, next, last)?
It appeared in 2.2.8.
What exactly is supposed to be written to it?
Mea culpa...
Further digging revealed that it's for returning prev in the
new
> > That's not the worst! Considering the 4-byte PTE and the
> 40-byte mem_map_t,
> > our memory management overhead is at least 44 bytes/page or 8.5%!
>
> use a logical page size of 4kb.
>
> > We are formulating cunning plans of aggregating 2, 4 or 8 pages together
> > into "bigpages", telling
> > We've kind of got 1.5-level page tables. There are actually 3
> page tables.
> > The system page table maps memory starting at 0x8000. The
> P0 process
> > page table maps from 0x0 up and the P1 process page table maps from
> > 0x7fff down.
>
> And they have to be physically
We've kind of got 1.5-level page tables. There are actually 3
page tables.
The system page table maps memory starting at 0x8000. The
P0 process
page table maps from 0x0 up and the P1 process page table maps from
0x7fff down.
And they have to be physically contiguous I guess
On Sun, Oct 15, 2000 at 09:45:11PM +0100, Alan Cox wrote:
> > Well, we ain't got these luxuries/complications in VAXland... Hell,
> > we don't even have two-level page tables :-(
>
> Really. Ugh. I always assumed Vax had at least two levels because mmap on
> 4.2 BSD used to panic on 128K+
On Sun, Oct 15, 2000 at 09:22:58PM +0100, Alan Cox wrote:
> > > or you have a sane memory management model with tags/spaces then its a non issue
> >
> > You've lost me here. Tags/spaces?
>
> A lot of memory management hardware allows you to build page tables that contain
> more than just the
On Sun, Oct 15, 2000 at 08:35:46PM +0100, Alan Cox wrote:
> > I understand that 2.4 no longer maps all physical memory as 2.2
> > and earlier used to do.
>
> Its really up to you if you choose to do that or not. If you have enough
> address space to create all your virtual and physical mappings
On Sun, Oct 15, 2000 at 08:07:06PM +0200, Andi Kleen wrote:
> On Sun, Oct 15, 2000 at 05:29:46PM +0100, Kenn Humborg wrote:
> >
> >
> > __pa() and __va() are still defined as addr -/+ PAGE_OFFSET. So
> > where did I hear about 2.4 not mapping all memory? Could it be
On Sun, Oct 15, 2000 at 06:03:40PM +0200, Erik Mouw wrote:
> On Sun, Oct 15, 2000 at 04:24:45PM +0100, Kenn Humborg wrote:
> > I understand that 2.4 no longer maps all physical memory as 2.2
> > and earlier used to do.
> >
> > Is there any documentation on this change
I understand that 2.4 no longer maps all physical memory as 2.2
and earlier used to do.
Is there any documentation on this change and how it affects
arch-specific code?
Specifically, we've been basing the VAX port on 2.2 while waiting
for 2.4 to stabilize. Now we're looking at moving to 2.4.
I understand that 2.4 no longer maps all physical memory as 2.2
and earlier used to do.
Is there any documentation on this change and how it affects
arch-specific code?
Specifically, we've been basing the VAX port on 2.2 while waiting
for 2.4 to stabilize. Now we're looking at moving to 2.4.
On Sun, Oct 15, 2000 at 08:07:06PM +0200, Andi Kleen wrote:
On Sun, Oct 15, 2000 at 05:29:46PM +0100, Kenn Humborg wrote:
Surprise!
__pa() and __va() are still defined as addr -/+ PAGE_OFFSET. So
where did I hear about 2.4 not mapping all memory? Could it be
that this applies only
On Sun, Oct 15, 2000 at 09:22:58PM +0100, Alan Cox wrote:
or you have a sane memory management model with tags/spaces then its a non issue
You've lost me here. Tags/spaces?
A lot of memory management hardware allows you to build page tables that contain
more than just the addresses.
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
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 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 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:
> > > >
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 being valid
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 them
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 in
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_SHIFT + 3
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
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
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 enoug
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
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
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 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. If
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 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
49 matches
Mail list logo
