On Mon, 1 Oct 2012 22:16:53 -0700
Tim Kientzle t...@kientzle.com wrote:
There are a few different parallel command-line compressors and decompressors
in ports; experiment a lot (with large files being read from and/or written
to disk) and see what the real effect is. In particular, some
.. please keep in mind that embedded platforms (a) don't necessarily
benefit from it, and (b) have a very small footprint. Bloating out the
compression/archival tools for the sake of possible SMP support will
make me very, very sad.
Adrian
___
Don't worry. I'm well known to over-optimize for both size and speed. I
have an old Pentium 3 800MHz single core that I can use to simulate an
embedded device (well, a decently powered one), to verify that I'm not
killing the single-core performance (I could add CPU capability
detection to
On Mon, Oct 01, 2012 at 10:16:53PM -0700, Tim Kientzle wrote:
* Implement within libarchive directly. This would benefit tar and
a handful of other programs that use libarchive, but may not be
worth the complexity.
The complexity shouldn't actually be that bad. Basically, use a
Garrett Wollman wrote:
I had an email conversation with Rick Macklem about six months ago
about NFS server bottlenecks. I'm now in a position to observe my
large-scale NFS server under an actual production load, so I thought I
would update folks on what it looks like. This is a 9.1 prerelease
On Monday, October 01, 2012 6:31:00 pm Simon J. Gerraty wrote:
Hi Garrett,
From: Garrett Cooper yaneg...@gmail.com
Subject: [CFT/RFC]: refactor bsd.prog.mk to understand multiple =
programs instead of a singular program
Date: September 2, 2012 11:01:09 PM PDT
To:
On Mon, Oct 1, 2012 at 5:00 PM, Simon J. Gerraty s...@juniper.net wrote:
Not to mention the fact that bsd.prog.mk goes from being relatively
simple, to unspeakably hard to read, and all for rather limited =
return.
This btw I think is the more important issue.
I was looking at bsd.prog.mk in
On Tue, Oct 2, 2012 at 4:50 AM, John Baldwin j...@freebsd.org wrote:
...
This sounds like a superior approach. It doesn't break any current use
cases while giving the ability to build multiple programs in the few
places that need it. It sounds like there are a few places under gnu/
from
On Tue, 2 Oct 2012 07:50:23 -0400, John Baldwin writes:
BTW, one general comment. There seem to be two completely independent
groups of folks working on ATF (e.g. there have been two different
imports of ATF into the tree in two different locations IIRC, and now
we have two different sets of
On Tue, 2 Oct 2012 07:19:55 -0700, Garrett Cooper writes:
We put the test cases in a subdir of the lib/prog
This has multiple benefits, and eliminates any impact on the normal
build of said libs/progs.
Hmmm... that's one of the 3 approaches I provided, but it turned out
to be annoying to make
On Tuesday, October 02, 2012 10:29:49 am Garrett Cooper wrote:
On Tue, Oct 2, 2012 at 4:50 AM, John Baldwin j...@freebsd.org wrote:
...
This sounds like a superior approach. It doesn't break any current use
cases while giving the ability to build multiple programs in the few
places
[Adding freebsd-fs@ to the Cc list, which I neglected the first time
around...]
On Tue, 2 Oct 2012 08:28:29 -0400 (EDT), Rick Macklem rmack...@uoguelph.ca
said:
I can't remember (I am early retired now;-) if I mentioned this patch before:
http://people.freebsd.org/~rmacklem/drc.patch
It
12 matches
Mail list logo
