On Wed, Oct 10, 2012 at 11:48:37AM -0400, Thor Lancelot Simon wrote:
> On Tue, Oct 09, 2012 at 05:59:06PM -0700, Chuck Silvers wrote:
> >
> > if so, then the reason for the 64k writes would be this block of code in
> > ffs_write():
> >
> > if (!async && oldoff >> 16 != uio->uio_offse
On Tue, Oct 09, 2012 at 05:59:06PM -0700, Chuck Silvers wrote:
>
> if so, then the reason for the 64k writes would be this block of code in
> ffs_write():
>
> if (!async && oldoff >> 16 != uio->uio_offset >> 16) {
> mutex_enter(vp->v_interlock);
>
On Wed, Oct 10, 2012 at 04:08:55PM +0200, Manuel Bouyer wrote:
> [...]
> I suspect UVM wants to do batch of read or writes in power of 2 size,
> aligned on power of 2 boundaries. Or this is my feeling after playing
> with the readahead code, and I wouldn't be surprised if the write
> code had the s
On Wed, Oct 10, 2012 at 10:48:10AM -0400, Thor Lancelot Simon wrote:
> On Wed, Oct 10, 2012 at 11:34:48AM +0200, Manuel Bouyer wrote:
> > On Tue, Oct 09, 2012 at 05:59:06PM -0700, Chuck Silvers wrote:
> > > > [...]
> > > > with a 'cat big_file > /dev/null'
> > > > writes are still limited to 64k ..
On Wed, Oct 10, 2012 at 11:34:48AM +0200, Manuel Bouyer wrote:
> On Tue, Oct 09, 2012 at 05:59:06PM -0700, Chuck Silvers wrote:
> > > [...]
> > > with a 'cat big_file > /dev/null'
> > > writes are still limited to 64k ...
> >
> > I would hope that cat'ing a file to /dev/null wouldn't result in any
On Wed, Oct 10, 2012 at 08:17:05AM -0400, Thor Lancelot Simon wrote:
> On Wed, Oct 10, 2012 at 11:34:48AM +0200, Manuel Bouyer wrote:
> >
> > I'm not sure what the best way to handle this would be.
> > If we assume that maxphys is a power of 2, we could use a maxphys-derived
> > mask here. Otherwi
On Wed, Oct 10, 2012 at 11:34:48AM +0200, Manuel Bouyer wrote:
>
> I'm not sure what the best way to handle this would be.
> If we assume that maxphys is a power of 2, we could use a maxphys-derived
> mask here. Otherwise, maybe we should compute and cache the largest power-of-2
> value below maxp
On Tue, Oct 09, 2012 at 05:59:06PM -0700, Chuck Silvers wrote:
> > [...]
> > with a 'cat big_file > /dev/null'
> > writes are still limited to 64k ...
>
> I would hope that cat'ing a file to /dev/null wouldn't result in any writes.
> :-)
> I assume you meant 'cat big_file > other_file' ?
I use:
On Tue, Oct 09, 2012 at 11:50:27PM +0200, Manuel Bouyer wrote:
> On Tue, Oct 09, 2012 at 11:13:52PM +0200, Manuel Bouyer wrote:
> > There is still a reference to MAXPHYS in ufs_bmaparray(), which, if I got
> > it right, will limit the *runp in VOP_BMAP(), which will limit iobytes
> > in genfs_do_io
On Tue, Oct 09, 2012 at 11:13:52PM +0200, Manuel Bouyer wrote:
> There is still a reference to MAXPHYS in ufs_bmaparray(), which, if I got
> it right, will limit the *runp in VOP_BMAP(), which will limit iobytes
> in genfs_do_io().
>
> but that doens't explain why I see 32k xfers. And, to make thi
On Tue, Oct 09, 2012 at 04:54:41PM -0400, Thor Lancelot Simon wrote:
> On Tue, Oct 09, 2012 at 10:15:06PM +0200, Manuel Bouyer wrote:
> >
> > Now, iostat -x shows that sequential read of a large file (either with cat
> > or dd bs=1m) is done in 32k transfers at the disk level. So I guess
> > some
On Tue, Oct 09, 2012 at 10:15:06PM +0200, Manuel Bouyer wrote:
>
> Now, iostat -x shows that sequential read of a large file (either with cat
> or dd bs=1m) is done in 32k transfers at the disk level. So I guess something
> is not working properly here ...
I saw that too, though I managed to get
On Tue, Oct 09, 2012 at 09:20:46AM -0700, Chuck Silvers wrote:
> > [...]
> > I wondered that myself. I think multiple of pagesize is probably okay,
> > but -- IIRC -- I couldn't convince myself we'd always do the right thing
> > with the residual. Try it?
>
> the underlying mechanism used by the
On Tue, Oct 09, 2012 at 05:35:44PM +0200, Manuel Bouyer wrote:
> On Tue, Oct 09, 2012 at 11:24:13AM -0400, Thor Lancelot Simon wrote:
> > On Tue, Oct 09, 2012 at 05:21:17PM +0200, Manuel Bouyer wrote:
> > > On Tue, Oct 09, 2012 at 11:04:20AM -0400, Thor Lancelot Simon wrote:
> > > > Hm.
> > > >
On Tue, Oct 09, 2012 at 11:24:13AM -0400, Thor Lancelot Simon wrote:
> On Tue, Oct 09, 2012 at 05:21:17PM +0200, Manuel Bouyer wrote:
> > On Tue, Oct 09, 2012 at 11:04:20AM -0400, Thor Lancelot Simon wrote:
> > > Hm.
> > >
> > > This will be an attempt to transfer an entire file -- 139264 will
On Tue, Oct 09, 2012 at 11:24:13AM -0400, Thor Lancelot Simon wrote:
> On Tue, Oct 09, 2012 at 05:21:17PM +0200, Manuel Bouyer wrote:
> > On Tue, Oct 09, 2012 at 11:04:20AM -0400, Thor Lancelot Simon wrote:
> > > Hm.
> > >
> > > This will be an attempt to transfer an entire file -- 139264 will
On Tue, Oct 09, 2012 at 05:21:17PM +0200, Manuel Bouyer wrote:
> On Tue, Oct 09, 2012 at 11:04:20AM -0400, Thor Lancelot Simon wrote:
> > Hm.
> >
> > This will be an attempt to transfer an entire file -- 139264 will be the
> > entire file size of something, probably an executable it's paging i
On Tue, Oct 09, 2012 at 11:04:20AM -0400, Thor Lancelot Simon wrote:
> Hm.
>
> This will be an attempt to transfer an entire file -- 139264 will be the
> entire file size of something, probably an executable it's paging in.
>
> I saw this before -- I can't remember what caused it -- the "bad
On Tue, Oct 09, 2012 at 03:50:18PM +0200, Manuel Bouyer wrote:
> On Tue, Oct 09, 2012 at 01:36:07PM +, Manuel Bouyer wrote:
> > [...]
> > Log Message:
> > Support transfers of up to MACHINE_MAXPHYS in all pciide variants, and ahci.
> > wd(4) limits its maxphys depending on the drives's capabili
On Tue, Oct 09, 2012 at 01:36:07PM +, Manuel Bouyer wrote:
> [...]
> Log Message:
> Support transfers of up to MACHINE_MAXPHYS in all pciide variants, and ahci.
> wd(4) limits its maxphys depending on the drives's capability (64k sectors
> for LBA48, 256 sectors for LBA and 128 sectors for olde
20 matches
Mail list logo
