On Sat, Sep 14, 2019 at 06:26:34AM +, Martin Husemann wrote:
> > Log Message:
> > Accept root device specification as NAME=label
[..]
> Why is this needed?
>
> I have been using
>
> config netbsd root on "wedge:Guru-Root" type ffs
>
> for ages (in the netbsd-7 branch
On Fri, Sep 13, 2019 at 01:33:20AM +, Emmanuel Dreyfus wrote:
> Module Name: src
> Committed By: manu
> Date: Fri Sep 13 01:33:20 UTC 2019
>
> Modified Files:
> src/sys/kern: kern_subr.c
>
> Log Message:
> Accept root device specification as NAME=label
>
>
> To generate a dif
> [...], because fexecve is causing rumbles about doing significantly
> more reverse lookups.
Why is everyone so concerned about finding "the" name of an inode, or
indeed any name for an inode? As far as I can tell there has never
been any promise that any given inode has any names pointing to it
On Fri 13 Sep 2019 at 18:04:06 +, David Holland wrote:
> On Wed, Sep 11, 2019 at 09:43:18AM +0300, Jason Thorpe wrote:
> > Another advantage of de-duping the name strings is that you can
> > compare names by testing pointer equivalence.
>
> I'd expect that trying to dedup the strings would d
In article <20190913180602.gb20...@netbsd.org>,
David Holland wrote:
>On Wed, Sep 11, 2019 at 03:53:18PM +0700, Robert Elz wrote:
> > What's more interesting to me is to know just how many long names people
> > are seeing which are currently excluded from the cache, and would benefit
> > from the
On Wed, Sep 11, 2019 at 03:53:18PM +0700, Robert Elz wrote:
> What's more interesting to me is to know just how many long names people
> are seeing which are currently excluded from the cache, and would benefit
> from the change - that is, what percentage of all lookups fail in the
> cache for
On Wed, Sep 11, 2019 at 09:43:18AM +0300, Jason Thorpe wrote:
> > I'm confused; nothing in there should lead to duplicate entries...
>
> Duplicate names != duplicate entries.
> [...]
> Another advantage of de-duping the name strings is that you can
> compare names by testing pointer equivale
On Fri, Sep 13, 2019 at 06:59:42AM -0400, Greg Troxel wrote:
> (I have not really been building current so am unclear on the xz
> details.)
>
> I'd like us to keep somewhat separate the notions of:
>
> someone is doing build.sh release
>
> someone wants min-size sets at the expense of a lot
Martin Husemann writes:
> On Fri, Sep 13, 2019 at 06:59:42AM -0400, Greg Troxel wrote:
>> I'd like us to keep somewhat separate the notions of:
>>
>> someone is doing build.sh release
>>
>> someone wants min-size sets at the expense of a lot of cpu time
>>
>>
>> I regularly do build.sh re
On Fri, Sep 13, 2019 at 07:06:59AM +0200, Martin Husemann wrote:
> I am not sure whether the xz compiled in tools supports the "-T threads"
> option, but if it does, we can add "-T 0" to the default args and see how
> much that improves things. Jörg, do you know this?
It doesn't currently, since i
On Fri, Sep 13, 2019 at 01:15:07PM +0200, Martin Husemann wrote:
> The default is MKDEBUG=no so you probably will not notice the compression
> difference that much.
>
> If you set MKDEBUG=yes you can just as easily set USE_XZ_SETS=no
> (or USE_PIGZGZIP=yes if you have pigz installed).
Or (evil ha
On Fri, Sep 13, 2019 at 06:59:42AM -0400, Greg Troxel wrote:
> I'd like us to keep somewhat separate the notions of:
>
> someone is doing build.sh release
>
> someone wants min-size sets at the expense of a lot of cpu time
>
>
> I regularly do build.sh release, and rsync the releasedir bits
"Tom Spindler (moof)" writes:
>> PS: The xz compression for the debug set takes 36 minutes on my machine.
>> We shoudl do something about it. Matt to use -T for more parallelism?
>
> On older machines, xz's default settings are pretty much unusable,
> and USE_XZ_SETS=no (or USE_PIGZGZIP=yes) is a
13 matches
Mail list logo
