On Sat, 6 Feb 2010, Ted Unangst wrote:
> On Sat, Feb 6, 2010 at 1:54 PM, Theo de Raadt
> wrote:
> >> How? cp reads 64k
> >
> > So change it to 1MB.
>
> Yeah, right, like anyone will ok a diff like that on the vax.
>
> > But using sysctl is insane. That is not portable.
>
> Why does cp need to b
On Sat, Feb 6, 2010 at 1:54 PM, Theo de Raadt
wrote:
>> How? cp reads 64k
>
> So change it to 1MB.
Yeah, right, like anyone will ok a diff like that on the vax.
> But using sysctl is insane. That is not portable.
Why does cp need to be portable? Who's porting OpenBSD cp to other systems?
On Sat, Feb 6, 2010 at 1:35 PM, Otto Moerbeek wrote:
> Add to that that doing I/O in big chunks is also putting more pressure
> on the buffer cache.
The buffer cache keeps a copy of whatever goes through it regardless
of size. The io is broken down into 64k chunks no matter what size cp
says to
Index: faq11.html
===
RCS file: /cvs/www/faq/faq11.html,v
retrieving revision 1.81
diff -u -p -r1.81 faq11.html
--- faq11.html 16 Oct 2009 19:07:37 - 1.81
+++ faq11.html 7 Feb 2010 01:18:54 -
@@ -92,7 +92,7 @@ computer.
Any feedback on this ?
--
Christiano Farina HAESBAERT
Do NOT send me html mail.
>> Date: Sat, 6 Feb 2010 13:32:46 +0100
>> From: Otto Moerbeek
>>
>> On Fri, Feb 05, 2010 at 09:24:30PM -0500, Ted Unangst wrote:
>>
>> > Though for a program like cp, this may qualify as a big diff. :)
>> >
>> > Continuing in my "make IO suck less" phase, cp would be a lot more
>> > efficien
> Now I look at the diff and see that the memory used is reasonably
> small. But still, if multiple copies of your cp are run together on a
> machine where available physical mem is low I might end up with a
> machine swapping. That is certainly not going to speed up cp.
If multiple copies of anyt
On 6 February 2010 11:37, Claus Assmann wrote:
>
> Putting that kind of "optimization" into programs that read/write
> large amount of data seems like the wrong way to go. It belongs in
> a central place.
>
> (That's just a comment from a clueless bystander...)
>
It belongs in *both* places. and
> How? cp reads 64k
So change it to 1MB.
But using sysctl is insane. That is not portable.
On Sat, Feb 06, 2010 at 12:58:21PM -0500, Ted Unangst wrote:
> On Sat, Feb 6, 2010 at 9:53 AM, Otto Moerbeek wrote:
...
> > your big buffers is that you are claiming resources even if you have
> > no idea if they are available or not.
>
> What resources? It uses a small fraction of your RAM.
On Sat, Feb 06, 2010, Ted Unangst wrote:
> cp writes 64k. How does the buffer cache optimize that into a larger
> write if cp hasn't even read the data yet? Does it hide the write on
> a secret "to be continued" queue? How long does it stay there? What
> if you're only writing to a part of the
On Sat, Feb 06, 2010 at 12:58:21PM -0500, Ted Unangst wrote:
> On Sat, Feb 6, 2010 at 9:53 AM, Otto Moerbeek wrote:
> > The buffer cache should ne smart enough to optmize read and writes in
> > such large chunks so that the seeking gets reduced. The problem with
>
> How? cp reads 64k. How much
> We're already seeing problems just making the buffer cache bigger.
> You think adding the complexity to optimize access patterns is going
> to make things better? cp at least has a very good idea of exactly
> what data it's going to need next. Putting heuristics in the kernel
> is exactly the w
On Sat, Feb 6, 2010 at 9:53 AM, Otto Moerbeek wrote:
> The buffer cache should ne smart enough to optmize read and writes in
> such large chunks so that the seeking gets reduced. The problem with
How? cp reads 64k. How much extra should the kernel read ahead? How
is this determined? What if y
Whenever I find myself wishing for such knobs, I simply install FreeBSD.
2010/2/6 Vadim Zhukov :
> On 6 February 2010 c. 17:53:09 Otto Moerbeek wrote:
>> On Sat, Feb 06, 2010 at 09:14:53AM -0500, Ted Unangst wrote:
>> > On Sat, Feb 6, 2010 at 8:44 AM, Mark Kettenis
> wrote:
>> > >> > Continuing i
On 6 February 2010 c. 17:53:09 Otto Moerbeek wrote:
> On Sat, Feb 06, 2010 at 09:14:53AM -0500, Ted Unangst wrote:
> > On Sat, Feb 6, 2010 at 8:44 AM, Mark Kettenis
wrote:
> > >> > Continuing in my "make IO suck less" phase, cp would be a lot
> > >> > more efficient if it didn't bounce the disk he
On Sat, Feb 06, 2010 at 09:14:53AM -0500, Ted Unangst wrote:
> On Sat, Feb 6, 2010 at 8:44 AM, Mark Kettenis wrote:
> >> > Continuing in my "make IO suck less" phase, cp would be a lot more
> >> > efficient if it didn't bounce the disk heads around so much. ?Instead of
> >> > using a tiny 64k buf
On Sat, Feb 6, 2010 at 8:44 AM, Mark Kettenis
wrote:
>> > Continuing in my "make IO suck less" phase, cp would be a lot more
>> > efficient if it didn't bounce the disk heads around so much. Instead of
>> > using a tiny 64k buffer, use an amount based on a small fraction of RAM.
>>
>> Isn't it th
> Date: Sat, 6 Feb 2010 13:32:46 +0100
> From: Otto Moerbeek
>
> On Fri, Feb 05, 2010 at 09:24:30PM -0500, Ted Unangst wrote:
>
> > Though for a program like cp, this may qualify as a big diff. :)
> >
> > Continuing in my "make IO suck less" phase, cp would be a lot more
> > efficient if it d
On Fri, Feb 05, 2010 at 09:24:30PM -0500, Ted Unangst wrote:
> Though for a program like cp, this may qualify as a big diff. :)
>
> Continuing in my "make IO suck less" phase, cp would be a lot more
> efficient if it didn't bounce the disk heads around so much. Instead of
> using a tiny 64k b
On 2010/02/05 20:30, Philip Guenther wrote:
> On Fri, Feb 5, 2010 at 6:14 PM, Ted Unangst wrote:
> > You are correct, but the patch isn't complete. You should be calling
> > fclose on the FILE *. Also, the table_write function has similar
> > bugs. I spent some time consolidating the error hand
On Tue, 2 Feb 2010 09:10:56 -0500
Okan Demirmen wrote:
> On Sun 2010.01.17 at 16:05 +0100, Thomas Pfaff wrote:
> > This diff disallows setting blank labels and pressing Esc while editing
> > the current one will leave it unchanged. I don't see the point in allowing
> > empty labels as the windows
Si ce message ne s'affiche pas correctement, visualisez la version en
ligne.
Le Collier Cravate, un bijou qui fait fureur !
Original, raffini et iligant
9,90 â¬*
300 modhles au choix
Un bijou pour toutes les occasions,
Un bijou pour tous les go{ts,
Un bijou pour toutes les tenues.
3 Collie
23 matches
Mail list logo
