Messages in this thread | | | Subject | Re: [RFC][PATCH] Expanding the size of "start" and "end" field in "struct resource" | From | (Eric W. Biederman) | Date | Wed, 15 Mar 2006 14:37:38 -0700 |
| |
"linux-os \(Dick Johnson\)" <linux-os@analogic.com> writes: > ix86 machines need to make many operations just to increment > or decrement a 64-bit variable, plus the operations are not > atomic so they need to be protected. The bloat of using 64-bit > objects in 32-bit machines is very real and a tremendous problem. > That's why all the stuff in the kernel wasn't 'long long' to > begin with. It's execution bloat, a.k.a., time expansion that > is the problem. > > Bump a 32-bit variable, addressed from an index register: > > incl (%ebx) > > Bump a 64-bit variable, addressed the same way. > > addl $1,(%ebx) ; Need to add because inc doesn't carry > adcl $0,4(%ebx) ; Add 0 plus the carry-flag > > If an interrupt or context-switch comes between the two operations, > the result is undefined, NotGood(tm).
No it is well defined it just isn't atomic. But difference. The thing is struct resource is accessed less often the file offsets which are already 64bit. Basically they are only used during driver initialization.
So while I agree in general that 64bit values should be avoided this is one of those places where we can productively use a 64bit value, on a 32bit machine.
To keep using 32bit kernels on the newer x86 machines at some point this will even become a requirement as 64bit BAR will actually have 64bit values placed in them.
Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |