On Mon, Aug 07, 2006 at 04:26:07PM -0600, Eric W. Biederman wrote:
> Adrian Bunk <[email protected]> writes:
>
> > On Mon, Aug 07, 2006 at 12:53:35PM -0600, Eric W. Biederman wrote:
> >>...
> >> --- a/arch/x86_64/Kconfig
> >> +++ b/arch/x86_64/Kconfig
> >> @@ -384,6 +384,20 @@ config NR_CPUS
> >> This is purely to save memory - each supported CPU requires
> >> memory in the static kernel configuration.
> >>
> >> +config NR_IRQS
> >> + int "Maximum number of IRQs (224-57344)"
> >
> > int "Maximum number of IRQs (224-57344)" depends on SMP
> >
> > This way, people with SMP=n will not see this question.
>
> I doubt it will be interesting but it might be, it is certainly
> well defined what happens when you have more irqs that a cpu
> has irq destinations.
The only effect of the user visibility of this option with SMP=n is that
the user might choose a higher value resulting in wasted space.
We do already have a big amount of options, there's no reason for
showing more than required.
> >> + range 224 57344
> >> + default "4096" if SMP
> >> + default "224" if !SMP
> >
> > Why not always
> > default "224"
> > ?
>
> A couple of reasons.
> - Things still need shaking out at the > 256 irq level and since
> this is going into -mm it is reasonable to have a large default.
For -mm, it might make even more sense defaulting to 57344 for getting a
better testing coverage.
This would give a good feedback of both space usage problems and the
timing behavior of all the
for (i = 0; i < NR_IRQS; i++)
loops in the kernel.
> - It is silly to have a default that won't work on some hardware,
> that we can support without unreasonable overhead.
So let's default NR_CPUS to 255 and NR_IRQS to 57344?
It's also silly if the defaults waste space (and time) for the majority
of users.
> - There are major simplicity gains to be had from a slight sparse
> irq space.
>
> - I haven't a clue what the irq numbers look like in the real world
> that we should be supporting since there was code in x86_64 and
> i386 to hack them up terribly. All I have a clue about are
> the really big machines. So I wouldn't be surprised if there
> were some small but I/O heavy machines that found 224 too limiting.
> I know of at least one uniprocessor machine that would have used
> almost all 224 irqs.
>
> - I want people to realize that we can easily have more than 256 irqs.
> With pure software interrupt sources and networking drivers allocating
> one irq per cpu the chances of us using our maximum allotment of irqs
> is much more likely in the next couple of years.
The common x86_64 SMP machine for sale today is a dual core desktop.
More than 224 IRQs are an exceptional case, and we can expect people
building such systems to know what they are doing.
> - 4096 is the number I expect distribution vendors will ship. Why set
> a different default than what you expect most people will use?
Defaults are not for distributions.
Distribution maintainers are expected to set such options not depending
on the defaults but depending on the needs of their users.
Depending on whether the distribution targets only desktop users, or
whether the primary target are big servers, 4096 might be wrong in any
direction.
> Eric
cu
Adrian
--
Gentoo kernels are 42 times more popular than SUSE kernels among
KLive users (a service by SUSE contractor Andrea Arcangeli that
gathers data about kernels from many users worldwide).
There are three kinds of lies: Lies, Damn Lies, and Statistics.
Benjamin Disraeli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
