Re: CONFIG_IRQBALANCE for 64-bit x86 ?

On Saturday 24 November 2007 00:09, Ingo Molnar wrote: > * Nick Piggin <[EMAIL PROTECTED]> wrote: > > Ahh, hate to get off topic, but let's not perpetuate this myth. It > > wasn't Con, or CFS, or anything that showed fairness is some great new > > idea. Actually I was arguing for fairness first, ag

Re: CONFIG_IRQBALANCE for 64-bit x86 ?

* Nick Piggin <[EMAIL PROTECTED]> wrote: > Ahh, hate to get off topic, but let's not perpetuate this myth. It > wasn't Con, or CFS, or anything that showed fairness is some great new > idea. Actually I was arguing for fairness first, against both Con and > Ingo, way back when the old scheduler

Re: CONFIG_IRQBALANCE for 64-bit x86 ?

On Wednesday 21 November 2007 06:07, Arjan van de Ven wrote: > On Wed, 21 Nov 2007 02:43:46 +1100 > > Of course it is, if you want to effectively use your resources. > > Imagine if the task balancer only polled once every 10s. > > but unlike the task balancer, moving an irq is really expensive. >

Re: CONFIG_IRQBALANCE for 64-bit x86 ?

Jeff Garzik wrote: Take a look at usr/Makefile for how initramfs is automatically included in the image, right now. The intention at the time was to quickly follow up this stub (generated by gen_init_cpio) with a full inclusion of klibc + some basics like nfsroot. It should be a very strai

Re: CONFIG_IRQBALANCE for 64-bit x86 ?

Ingo Molnar wrote: single-bzImage initrd was and is possible, Correct (though s/initrd/initramfs/). Take a look at usr/Makefile for how initramfs is automatically included in the image, right now. The intention at the time was to quickly follow up this stub (generated by gen_init_cpio) wit

Re: CONFIG_IRQBALANCE for 64-bit x86 ?

On Tue, 20 Nov 2007 15:17:15 +1100 Nick Piggin <[EMAIL PROTECTED] > wrote: > On Tuesday 20 November 2007 15:12, Mark Lord wrote: > > On 32-bit x86, we have CONFIG_IRQBALANCE available, > > but not on 64-bit x86. Why not? because the in-kernel one is actually quite bad

Re: CONFIG_IRQBALANCE for 64-bit x86 ?

Ingo Molnar wrote: i took that "Nope" as referring to my impression - but you in fact meant that i am not wrong? :-) So nothing to see here. single-bzImage initrd was and is possible, so we could in fact move chunks of system-related userland (such as irqbalanced) into the kernel proper?

Re: CONFIG_IRQBALANCE for 64-bit x86 ?

* H. Peter Anvin <[EMAIL PROTECTED]> wrote: > Ingo Molnar wrote: >> * H. Peter Anvin <[EMAIL PROTECTED]> wrote: >> > Nope. It runs inside an initramfs, of course; that initramfs is linked > into the kernel binary. would be nice to have a single-image variant for all of this. having

Re: CONFIG_IRQBALANCE for 64-bit x86 ?

Ingo Molnar wrote: * H. Peter Anvin <[EMAIL PROTECTED]> wrote: Nope. It runs inside an initramfs, of course; that initramfs is linked into the kernel binary. would be nice to have a single-image variant for all of this. having the separate initrd was always trouble - and it's pointless as wel

Re: CONFIG_IRQBALANCE for 64-bit x86 ?

* H. Peter Anvin <[EMAIL PROTECTED]> wrote: >>> Nope. It runs inside an initramfs, of course; that initramfs is >>> linked into the kernel binary. >> >> would be nice to have a single-image variant for all of this. having >> the separate initrd was always trouble - and it's pointless as well.

Re: CONFIG_IRQBALANCE for 64-bit x86 ?

Ingo Molnar wrote: * H. Peter Anvin <[EMAIL PROTECTED]> wrote: Ingo Molnar wrote: * Mark Lord <[EMAIL PROTECTED]> wrote: Perhaps, but this also violates the principle that the kernel should just *work* with sensible defaults. I don't use an initrd, or an initramfs, and have no intention of

Re: CONFIG_IRQBALANCE for 64-bit x86 ?

* H. Peter Anvin <[EMAIL PROTECTED]> wrote: > Ingo Molnar wrote: >> * Mark Lord <[EMAIL PROTECTED]> wrote: >> >>> Perhaps, but this also violates the principle that the kernel should just >>> *work* with sensible defaults. I don't use an initrd, or an initramfs, >>> and have no intention of ev

Re: CONFIG_IRQBALANCE for 64-bit x86 ?

Ingo Molnar wrote: * Mark Lord <[EMAIL PROTECTED]> wrote: Perhaps, but this also violates the principle that the kernel should just *work* with sensible defaults. I don't use an initrd, or an initramfs, and have no intention of ever doing so. nor do i - i was under the impression that klibc

Re: CONFIG_IRQBALANCE for 64-bit x86 ?

Mark Lord wrote: Perhaps, but this also violates the principle that the kernel should just *work* with sensible defaults. I don't use an initrd, or an initramfs, and have no intention of ever doing so. I *like* having a single boot image with no unneeded/unwanted complexity. It's only recently

Re: CONFIG_IRQBALANCE for 64-bit x86 ?

* Mark Lord <[EMAIL PROTECTED]> wrote: > Perhaps, but this also violates the principle that the kernel should > just *work* with sensible defaults. I don't use an initrd, or an > initramfs, and have no intention of ever doing so. nor do i - i was under the impression that klibc was able to wo

Re: CONFIG_IRQBALANCE for 64-bit x86 ?

Ingo Molnar wrote: * Arjan van de Ven <[EMAIL PROTECTED]> wrote: kernel or kernel source? If there was a good place in the kernel source I'd not be against moving irqbalance there. [...] would this be a good case study to use klibc and start up irqbalanced automatically? I'd love it if we mo

Re: CONFIG_IRQBALANCE for 64-bit x86 ?

Arjan van de Ven wrote: On Tue, 20 Nov 2007 15:02:43 -0500 Mark Lord <[EMAIL PROTECTED]> wrote: .. Well, for my dualCore notebook, dualCore MythTV box, and QuadCore desktop, the behaviour of the existing, working, 32-bit kernel IRQBALANCE code outperforms the userspace utility. Mostly, I suspe

Re: CONFIG_IRQBALANCE for 64-bit x86 ?

On Tue, 20 Nov 2007 15:02:43 -0500 Mark Lord <[EMAIL PROTECTED]> wrote: > .. > > Well, for my dualCore notebook, dualCore MythTV box, and QuadCore > desktop, the behaviour of the existing, working, 32-bit kernel > IRQBALANCE code outperforms the userspace utility. > > Mostly, I suspect, due to it

Re: CONFIG_IRQBALANCE for 64-bit x86 ?

* Arjan van de Ven <[EMAIL PROTECTED]> wrote: > kernel or kernel source? If there was a good place in the kernel > source I'd not be against moving irqbalance there. [...] would this be a good case study to use klibc and start up irqbalanced automatically? I'd love it if we moved more of the '

Re: CONFIG_IRQBALANCE for 64-bit x86 ?

Arjan van de Ven wrote: On Wed, 21 Nov 2007 02:43:46 +1100 Nick Piggin <[EMAIL PROTECTED]> wrote: On Wednesday 21 November 2007 01:47, Arjan van de Ven wrote: On Tue, 20 Nov 2007 18:37:39 +1100 Nick Piggin <[EMAIL PROTECTED]> wrote: actually no. IRQ balancing is not a "fast" decision; ev

Re: CONFIG_IRQBALANCE for 64-bit x86 ?

Nick Piggin <[EMAIL PROTECTED]> writes: > > For that matter, I'd like to know why it has been decided that the > best place for IRQ balancing is in userspace. There is a lot of possible policy in it > It should be in kernel > IMO, and it would probably allow better power saving, performance, > f

Re: CONFIG_IRQBALANCE for 64-bit x86 ?

On Wed, 21 Nov 2007 02:43:46 +1100 Nick Piggin <[EMAIL PROTECTED]> wrote: > On Wednesday 21 November 2007 01:47, Arjan van de Ven wrote: > > On Tue, 20 Nov 2007 18:37:39 +1100 > > > > Nick Piggin <[EMAIL PROTECTED]> wrote: > > > > actually no. IRQ balancing is not a "fast" decision; every > >

Re: CONFIG_IRQBALANCE for 64-bit x86 ?

(resending this one to the list). Arjan van de Ven wrote: On Tue, 20 Nov 2007 10:47:24 -0500 Mark Lord <[EMAIL PROTECTED]> wrote: .. After reading some of the replies, I installed it on my malfunctioning 64-bit system, but discovered it does not perform nearly as well as the kernel solution in

Re: CONFIG_IRQBALANCE for 64-bit x86 ?

Arjan van de Ven wrote: On Tue, 20 Nov 2007 10:52:48 -0500 Mark Lord <[EMAIL PROTECTED]> wro All of which reminds me of perhaps *the* most important reason to keep core functionality like "IRQ distribution" *inside* the kernel: It has to pass peer review on this mailing list. that's a rea

Re: CONFIG_IRQBALANCE for 64-bit x86 ?

On Tue, 20 Nov 2007 10:52:48 -0500 Mark Lord <[EMAIL PROTECTED]> wro > > All of which reminds me of perhaps *the* most important reason to keep > core functionality like "IRQ distribution" *inside* the kernel: > >It has to pass peer review on this mailing list. that's a reason to keep it in

Re: CONFIG_IRQBALANCE for 64-bit x86 ?

On Wednesday 21 November 2007 01:47, Arjan van de Ven wrote: > On Tue, 20 Nov 2007 18:37:39 +1100 > > Nick Piggin <[EMAIL PROTECTED]> wrote: > > > actually no. IRQ balancing is not a "fast" decision; every time > > > you > > > > I didn't say anything of the sort. But IRQ load could still fluctu

Re: CONFIG_IRQBALANCE for 64-bit x86 ?

Mark Lord wrote: Arjan van de Ven wrote: .. I listed a few; 1) it's policy 2) the memory is only needed for a short time (20 seconds or so) on single-socket machines 3) it makes decisions on "subjective" information such as interrupt device classes that the kernel currently just doesn't have (

Re: CONFIG_IRQBALANCE for 64-bit x86 ?

Arjan van de Ven wrote: .. I listed a few; 1) it's policy 2) the memory is only needed for a short time (20 seconds or so) on single-socket machines 3) it makes decisions on "subjective" information such as interrupt device classes that the kernel currently just doesn't have (it could grow that

Re: CONFIG_IRQBALANCE for 64-bit x86 ?

On Tue, 20 Nov 2007 18:37:39 +1100 Nick Piggin <[EMAIL PROTECTED]> wrote: > > actually no. IRQ balancing is not a "fast" decision; every time > > you > > I didn't say anything of the sort. But IRQ load could still fluctuate > a lot more rapidly than we'd like to wake up the irqbalancer. irq l

Re: CONFIG_IRQBALANCE for 64-bit x86 ?

On Tuesday 20 November 2007 16:37, Arjan van de Ven wrote: > On Tue, 20 Nov 2007 15:17:15 +1100 > > For that matter, I'd like to know why it has been decided that the > > best place for IRQ balancing is in userspace. It should be in kernel > > IMO, and it would probably allow better power saving,

Re: CONFIG_IRQBALANCE for 64-bit x86 ?

On Tue, 20 Nov 2007 15:17:15 +1100 Nick Piggin <[EMAIL PROTECTED]> wrote: > On Tuesday 20 November 2007 15:12, Mark Lord wrote: > > On 32-bit x86, we have CONFIG_IRQBALANCE available, > > but not on 64-bit x86. Why not? because the in-kernel one is actually quite bad. > > My QuadCore box works

Re: CONFIG_IRQBALANCE for 64-bit x86 ?

Nick Piggin wrote: On Tuesday 20 November 2007 15:37, Adrian Bunk wrote: On Tue, Nov 20, 2007 at 05:29:29AM +0100, Willy Tarreau wrote: Agreed. When userspace has something to do with the way IRQs are delivered, it's going to smell as bad as micro-kernels... The next step to a micro-kernel w

Re: CONFIG_IRQBALANCE for 64-bit x86 ?

On Tuesday 20 November 2007 15:37, Adrian Bunk wrote: > On Tue, Nov 20, 2007 at 05:29:29AM +0100, Willy Tarreau wrote: > > Agreed. When userspace has something to do with the way IRQs are > > delivered, it's going to smell as bad as micro-kernels... > > The next step to a micro-kernel would then b

Re: CONFIG_IRQBALANCE for 64-bit x86 ?

On Tue, Nov 20, 2007 at 05:29:29AM +0100, Willy Tarreau wrote: > On Tue, Nov 20, 2007 at 03:17:15PM +1100, Nick Piggin wrote: > > On Tuesday 20 November 2007 15:12, Mark Lord wrote: > > > On 32-bit x86, we have CONFIG_IRQBALANCE available, > > > but not on 64-bit x86. Why not? > > > > > > I ask, b

Re: CONFIG_IRQBALANCE for 64-bit x86 ?

On Tue, Nov 20, 2007 at 03:17:15PM +1100, Nick Piggin wrote: > On Tuesday 20 November 2007 15:12, Mark Lord wrote: > > On 32-bit x86, we have CONFIG_IRQBALANCE available, > > but not on 64-bit x86. Why not? > > > > I ask, because this feature seems almost essential to obtaining > > reasonable late

Re: CONFIG_IRQBALANCE for 64-bit x86 ?

On Tuesday 20 November 2007 15:12, Mark Lord wrote: > On 32-bit x86, we have CONFIG_IRQBALANCE available, > but not on 64-bit x86. Why not? > > I ask, because this feature seems almost essential to obtaining > reasonable latencies during heavy I/O with fast devices. > > My 32-bit Core2Duo MythTV b

Re: CONFIG_IRQBALANCE for 64-bit x86 ?

Tuesday 20 November 2007 Tarihinde 06:12:21 yazmıştı: > On 32-bit x86, we have CONFIG_IRQBALANCE available, > but not on 64-bit x86. Why not? > > I ask, because this feature seems almost essential to obtaining > reasonable latencies during heavy I/O with fast devices. > > My 32-bit Core2Duo MythTV

CONFIG_IRQBALANCE for 64-bit x86 ?

On 32-bit x86, we have CONFIG_IRQBALANCE available, but not on 64-bit x86. Why not? I ask, because this feature seems almost essential to obtaining reasonable latencies during heavy I/O with fast devices. My 32-bit Core2Duo MythTV box drops audio frames without it, but works perfectly *with* IR