Re: 64-bit block sizes on 32-bit systems

LA Walsh (law@sgi.com)
Mon, 26 Mar 2001 09:35:10 -0800


Matthew Wilcox wrote:
>
> On Mon, Mar 26, 2001 at 08:39:21AM -0800, LA Walsh wrote:
> > I vaguely remember a discussion about this a few months back.
> > If I remember, the reasoning was it would unnecessarily slow
> > down smaller systems that would never have block devices in
> > the 4-28T range attached.
>
> 4k page size * 2GB = 8TB.
---
        Drat...was being more optimistic -- you're right
the block_nr can be negative.  Somehow thought page size could
be 8K....living in future land.  That just makes the limitations
even closer at hand...:-(

> you keep on trying to increase the size of types without looking at > what gcc outputs in the way of code that manipulates 64-bit types.

---
        Maybe someone will backport some of the features of the
IA-64 code generator into 'gcc'.  I've been told that in some 
cases it's a 2.5x performance difference.  If 'gcc' is generating
bad code, then maybe the 'gcc' people will increase the quality
of their code -- I'm sure they are just as eagerly working on
gcc improvements as we are kernel improvements.  When I worked
on the PL/M compiler project at Intel, I know our code-optimization
guy would spend endless cycles trying to get better optimization
out of the code.  He got great joy out of doing so. -- and
that was almost 20 years ago -- and code generation has come
a *long* way since then.

> seriously, why don't you just try it? see what the performance is. > see what the code size is. then come back with some numbers. and i mean > numbers, not `it doesn't feel any slower'.

---
        As for 'trying' it -- would anyone care if we virtualized
the block_nr into a typedef?  That seems like it would provide
for cleaner (type-checked) code at no performance penalty and
more easily allow such comparisons.

Well this is my point: if I have disks > 8T, wouldn't it be at *all* beneficial to be able to *choose* some slight performance impact and access those large disks vs. having not choice? Having it as a configurable would allow a given installation to make that choice rather than them having no choice. BTW, are block_nr's on RAID arrays subject to this limitation? > > personally, i'm going to see what the situation looks like in 5 years time > and try to solve the problem then.

---
        It's not the same, but SGI has had customers for over
3 years using >2T *files*.  The point I'm looking at is if
the P-X series gets developed enough, and someone is using a
4-16P system, a corp user might be approaching that limit
today or tomorrow.  Joe User, might not for 5 years, but that's
what the configurability is about.  Keep linux usable for both
ends of the scale -- "I love scalability"....

-l

-- 
L A Walsh                        | Trust Technology, Core Linux, SGI
law@sgi.com                      | Voice: (650) 933-5338
-- 
L A Walsh                        | Trust Technology, Core Linux, SGI
law@sgi.com                      | Voice: (650) 933-5338
-
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/