On Wed, May 09, 2001 at 05:03:06PM +0200, Reto Baettig wrote:
> Jeff Garzik schrieb:
> >
> > Martin Dalecki wrote:
> > > > - I force the virtual blocksize for all the blkdev I/O
> > > > (buffered and direct) to work with a 4096 bytes granularity instead of
> > >
> > > You mean PAGE_SIZE :-).
>
Jeff Garzik schrieb:
>
> Martin Dalecki wrote:
> > > - I force the virtual blocksize for all the blkdev I/O
> > > (buffered and direct) to work with a 4096 bytes granularity instead of
> >
> > You mean PAGE_SIZE :-).
Or maybe 8192 bytes on alphas ?!? ;-)
-
To unsubscribe from this list: send t
er_head?
>
> I wouldn't be that trivial to drop it, not much different than dropping
> it when a fs has a 4k blocksize. I think the dynamic allocation of the
> bh is not that a bad thing, or at least it's an orthogonal problem to
> moving the blkdev in pagecache ;).
I thin
On Wed, May 09 2001, Andrea Arcangeli wrote:
> On Wed, May 09, 2001 at 04:14:52PM +0200, Jens Axboe wrote:
> > better to stay with PAGE_CACHE_SIZE and not get into dark country :-)
>
> My whole point for not using PAGE_CACHE_SIZE as virtual blocksize is
> that many architectures have a PAGE_CACHE
On Wed, May 09, 2001 at 04:14:52PM +0200, Jens Axboe wrote:
> better to stay with PAGE_CACHE_SIZE and not get into dark country :-)
My whole point for not using PAGE_CACHE_SIZE as virtual blocksize is
that many architectures have a PAGE_CACHE_SIZE > 4k, up to 64k, on
x86-64 we may even hack a 2M
On Wed, May 09 2001, Andrea Arcangeli wrote:
> On Wed, May 09, 2001 at 11:13:33AM +0200, Martin Dalecki wrote:
> > > (buffered and direct) to work with a 4096 bytes granularity instead of
> >
> > You mean PAGE_SIZE :-).
>
> In my first patch it is really 4096 bytes, but yes I agree we should
>
think the dynamic allocation of the
bh is not that a bad thing, or at least it's an orthogonal problem to
moving the blkdev in pagecache ;).
> Basically this is something which should come down to the strategy
> routine
> of the corresponding device and be fixed there... And then we h
Martin Dalecki wrote:
> > - I force the virtual blocksize for all the blkdev I/O
> > (buffered and direct) to work with a 4096 bytes granularity instead of
>
> You mean PAGE_SIZE :-).
Or maybe PAGE_CACHE_SIZE?
--
Jeff Garzik | Game called on account of naked chick
Building 1024|
Man
Andrea Arcangeli wrote:
> (btw, also the current rawio uses a 512byte bh->b_size granularity that is even
> worse than the 1024byte b_size of the blkdev, O_DIRECT is much smarter
> on this side as it uses the softblocksize of the fs that can be as well
> 4k if you created the fs with -b 4096)
Am
ot;usable" in real life I needed to fix
it. But I didn't wanted ot invest any further time on such an hack and I
preferred to move the blkdev in pagecache and to fix the problem on top
of the new better design (moving blkdev in pagecache of course
introduces that same problem too as I also m
10 matches
Mail list logo
