Re: [RFC][PATCH] Expanding the size of "start" and "end" field in "struct resource"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Benjamin LaHaise <[email protected]> writes:

> On Wed, Mar 15, 2006 at 02:59:54PM -0700, Eric W. Biederman wrote:
>> Actually now that I think back there are machines with < 4GiB of ram
>> with 64bit pci BAR values.  It is more common to have 32bit values BAR
>> values and > 4GiB of ram.
>
> Such machines on x86 would have to be compiled with PAE.  Ditto any other 
> architecture, as you *have* to be able to represent those physical addresses, 
> which requires having page tables that can map them, which requires whatever 
> PAE is on the platform.

It depends on who the user is.  In the case that inspired this thread
user space can profit from the information even when the kernel can't.
In addition it appears kernel code quality can benefit as well.

>> Nor do I think struct resource is nearly as important when being
>> efficient, as dma_addr_t.  struct resource is only used during
>> driver setup which is a very rare event.  A few extra instructions
>> there likely will get lost in the noise and most of the will probably
>> be removed because they are in an __init section anyway.
>
> Bloat for no good reason is a bad habit to get into.

I agree bloat for no good reason is a bad habit to get into.
Premature optimization is a worse habit to get into, as is making
problems unnecessarily complex.  Until working patches are produced,
and the impact can be assessed it is to soon to seriously worry about
something that back of the napkin calculations indicate suggest
will have no measurable impact.

Eric

-
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]
  Powered by Linux