On Thu, May 14, 2015 at 08:53:05AM -0600, Ian Lepore wrote:
> At least I'm inclined to ponder it. Apparently nobody else is. People
> running servers with more GB of ram than grains of sand on the beach
> won't care about things like 64k buffers used by /bin/sh to read a line
> of text, and all
In message <5554b8d6.1010...@mu.org>, Alfred Perlstein writes:
>Shouldn't most of these be using st.st_blksize ?
We had a long discussion about that back when GEOM was young and the
conclusionis that st_blksize doesn't tell you anything useful
and generally does the wrong thing, in parti
In message <1431615185.1221.57.ca...@freebsd.org>, Ian Lepore writes:
>I think we've got differing interpretations of what BUFSIZ is for.
>
>IMO, the one correct use of BUFSIZ outside of libc is "if you are going
>to call setbuf() the buffer you pass must be BUFSIZ bytes long."
>
>Over th
On 5/14/15 2:23 AM, Garrett Cooper wrote:
On May 14, 2015, at 1:06, Poul-Henning Kamp wrote:
In message <20150514075316.gy37...@funkthat.com>, John-Mark Gurney writes:
Poul-Henning Kamp wrote this message on Thu, May 14, 2015 at 07:42 +:
In message <20150514072155.gt3
On Thu, 2015-05-14 at 07:42 +, Poul-Henning Kamp wrote:
>
> In message <20150514072155.gt37...@funkthat.com>, John-Mark Gurney writes:
>
> >Since you apprently missed my original reply, I said that we shouldn't
> >abuse BUFSIZ for this work, and that it should be changed in mdXhl.c...
In message <72720ea2-c251-40b9-9ec0-702c07d5e...@gmail.com>, Garrett Cooper
writes:
>Until performance has been characterized on 32-bit vs
>64-bit architectures, blanket changing a value doesn't make sense.
First time I saw benchmarks which showed improved performance
from a larger BUF
On May 14, 2015, at 1:01, Poul-Henning Kamp wrote:
>
> In message <1431542835.1221.30.ca...@freebsd.org>, Ian Lepore writes:
>> On Wed, 2015-05-13 at 11:13 -0700, John-Mark Gurney wrote:
>
>> As I've already pointed out, BUFSIZ appears in the
>> base code over 2000 times. Where is the
On May 14, 2015, at 1:06, Poul-Henning Kamp wrote:
>
> In message <20150514075316.gy37...@funkthat.com>, John-Mark Gurney writes:
>> Poul-Henning Kamp wrote this message on Thu, May 14, 2015 at 07:42 +:
>>>
>>> In message <20150514072155.gt37...@funkthat.com>, John-Mark Gurn
In message <20150514075316.gy37...@funkthat.com>, John-Mark Gurney writes:
>Poul-Henning Kamp wrote this message on Thu, May 14, 2015 at 07:42 +:
>>
>> In message <20150514072155.gt37...@funkthat.com>, John-Mark Gurney writes:
>>
>> >Since you apprently missed my original rep
In message <1431542835.1221.30.ca...@freebsd.org>, Ian Lepore writes:
>On Wed, 2015-05-13 at 11:13 -0700, John-Mark Gurney wrote:
>As I've already pointed out, BUFSIZ appears in the
>base code over 2000 times. Where is the analysis of the impact an 8x
>change is going to have on all thos
Poul-Henning Kamp wrote this message on Thu, May 14, 2015 at 07:42 +:
>
> In message <20150514072155.gt37...@funkthat.com>, John-Mark Gurney writes:
>
> >Since you apprently missed my original reply, I said that we shouldn't
> >abuse BUFSIZ for this work, and that it should be changed
In message <20150514072155.gt37...@funkthat.com>, John-Mark Gurney writes:
>Since you apprently missed my original reply, I said that we shouldn't
>abuse BUFSIZ for this work, and that it should be changed in mdXhl.c...
Say what ?
BUFSIZ is used entirely appropriately in MDXFileChunk():
David Chisnall wrote this message on Wed, May 13, 2015 at 09:27 +0100:
> On 13 May 2015, at 09:03, John-Mark Gurney wrote:
> >
> > Poul-Henning Kamp wrote this message on Tue, May 12, 2015 at 06:31 +:
> >>
> >> In message <20150512032307.gp37...@funkthat.com>, John-Mark Gurney writes
Ian Lepore wrote this message on Wed, May 13, 2015 at 12:47 -0600:
> On Wed, 2015-05-13 at 11:13 -0700, John-Mark Gurney wrote:
> > Adrian Chadd wrote this message on Wed, May 13, 2015 at 08:34 -0700:
> > > The reason I ask about "why is it faster?" is because for embedded-y
> > > things with low R
On Wed, 2015-05-13 at 11:13 -0700, John-Mark Gurney wrote:
> Adrian Chadd wrote this message on Wed, May 13, 2015 at 08:34 -0700:
> > The reason I ask about "why is it faster?" is because for embedded-y
> > things with low RAM we may not want that to happen due to memory
> > constraints. However, w
Adrian Chadd wrote this message on Wed, May 13, 2015 at 08:34 -0700:
> The reason I ask about "why is it faster?" is because for embedded-y
> things with low RAM we may not want that to happen due to memory
> constraints. However, we may actually want to do some form of
> autotuning on some platfor
Hans Petter Selasky wrote this message on Wed, May 13, 2015 at 10:35 +0200:
> On 05/13/15 10:27, David Chisnall wrote:
> > On 13 May 2015, at 09:03, John-Mark Gurney wrote:
> >>
> >> Poul-Henning Kamp wrote this message on Tue, May 12, 2015 at 06:31 +:
> >>>
> >>> In message <20150512
[snip]
The reason I ask about "why is it faster?" is because for embedded-y
things with low RAM we may not want that to happen due to memory
constraints. However, we may actually want to do some form of
autotuning on some platforms.
So, if it's underlying block size, maybe BUFSIZ isn't the thing
On Wed, 2015-05-13 at 10:35 +0200, Hans Petter Selasky wrote:
> On 05/13/15 10:27, David Chisnall wrote:
> > On 13 May 2015, at 09:03, John-Mark Gurney wrote:
> >>
> >> Poul-Henning Kamp wrote this message on Tue, May 12, 2015 at 06:31 +:
> >>>
> >>> In message <20150512032307.gp37...
On 05/13/15 10:27, David Chisnall wrote:
On 13 May 2015, at 09:03, John-Mark Gurney wrote:
Poul-Henning Kamp wrote this message on Tue, May 12, 2015 at 06:31 +:
In message <20150512032307.gp37...@funkthat.com>, John-Mark Gurney writes:
Also, you'd probably see even better perfo
On 13 May 2015, at 09:03, John-Mark Gurney wrote:
>
> Poul-Henning Kamp wrote this message on Tue, May 12, 2015 at 06:31 +:
>>
>> In message <20150512032307.gp37...@funkthat.com>, John-Mark Gurney writes:
>>
>>> Also, you'd probably see even better performance by increasing the
>>>
Poul-Henning Kamp wrote this message on Tue, May 12, 2015 at 06:31 +:
>
> In message <20150512032307.gp37...@funkthat.com>, John-Mark Gurney writes:
>
> >Also, you'd probably see even better performance by increasing the
> >size to 64k, [...]
>
> easy:
> 8K on 32bit
> 64k
On Tue, May 12, 2015 at 06:31:33AM +, Poul-Henning Kamp wrote:
> >Also, you'd probably see even better performance by increasing the
> >size to 64k, [...]
>
> easy:
> 8K on 32bit
> 64k on 64bit
Need benchmarking.
May be 16K is local maximum (L1 cache-efficient).
_
In message <20150512032307.gp37...@funkthat.com>, John-Mark Gurney writes:
>Also, you'd probably see even better performance by increasing the
>size to 64k, [...]
easy:
8K on 32bit
64k on 64bit
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org
4k block size on the underlying device?
On 12/05/2015 00:14, Adrian Chadd wrote:
So I'm curious - why's it faster?
-adrian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any
Baptiste Daroussin wrote this message on Tue, May 12, 2015 at 01:06 +0200:
> I would like to change the default value of BUFSIZ to 8192.
>
> After testing various applications that uses BUFSIZ like changing it in libmd
> I
> can often see performance improvements:
>
> For example with md5(1):
>
So I'm curious - why's it faster?
-adrian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Hi,
I would like to change the default value of BUFSIZ to 8192.
After testing various applications that uses BUFSIZ like changing it in libmd I
can often see performance improvements:
For example with md5(1):
Current BUFSIZ (1024)
0.13 real 0.04 user 0.09 sys
New BUFSIZ (8192)
0.
28 matches
Mail list logo
