On Oct 5, 2012, at 10:08 AM, John Baldwin wrote:
> On Thursday, October 04, 2012 1:20:52 pm Carl Delsey wrote:
>> I noticed that the bus_space_*_8 functions are unimplemented for x86.
>> Looking at the code, it seems this is intentional.
>>
>> Is this done because on 32-bit systems we don't kno
I was trying to co-relate the o/p from "top" to that I get from vmstat -z. I
don't have any user programs that wires memory. Given that, I'm assuming the
wired memory count shown by "top" is memory used by kernel. Now I would like
find out how the kernel is using this "wired" memory. So, I look
Not necessarily. If I understand correctly what Tim means, he's talking
about an in-memory compression of several blocks by several separate
threads, and then - after all the threads have compressed their
respective blocks - writing out the result to the output file in order.
Of course, this woul
[snip]
> any fix?
> > You have found the fix. Remove the WITHOUT_ options from the build
> > that keep it from completing. You'll be able to add them at installworld
> > time w/o a hassle. nanobsd uses this to keep things down, while still
> > being able to build the system.
> > Warner
>
On Oct 9, 2012, at 3:46 AM, Daniel Braniss wrote:
> [snip]
>> any fix?
>>> You have found the fix. Remove the WITHOUT_ options from the build
>>> that keep it from completing. You'll be able to add them at installworld
>>> time w/o a hassle. nanobsd uses this to keep things down, while s
On Oct 4, 2012, at 12:36 AM, Rick Macklem wrote:
> Garrett Wollman wrote:
>> <> said:
>>
Simple: just use a sepatate mutex for each list that a cache entry
is on, rather than a global lock for everything. This would reduce
the mutex contention, but I'm not sure how significantly
On Oct 9, 2012, at 5:12 PM, Nikolay Denev wrote:
>
> On Oct 4, 2012, at 12:36 AM, Rick Macklem wrote:
>
>> Garrett Wollman wrote:
>>> <>> said:
>>>
> Simple: just use a sepatate mutex for each list that a cache entry
> is on, rather than a global lock for everything. This would reduc
Hi list,
I'm looking at this possible divide-by zero in dhclient:
http://scan.freebsd.your.org/freebsd-head/WORLD/2012-10-07-amd64/report-nBhqE2.html.gz#EndPath
In this specific case, it's obvious from the intention of the code that
ip->client->interval is always >0, but it's not obvious to me
On Tue, 2012-10-09 at 17:35 +0200, Erik Cederstrand wrote:
> Hi list,
>
> I'm looking at this possible divide-by zero in dhclient:
> http://scan.freebsd.your.org/freebsd-head/WORLD/2012-10-07-amd64/report-nBhqE2.html.gz#EndPath
>
> In this specific case, it's obvious from the intention of the co
On Oct 9, 2012, at 4:46 AM, Daniel Braniss wrote:
> [snip]
>> any fix?
>>> You have found the fix. Remove the WITHOUT_ options from the build
>>> that keep it from completing. You'll be able to add them at installworld
>>> time w/o a hassle. nanobsd uses this to keep things down, while s
On Monday, October 08, 2012 4:59:24 pm Warner Losh wrote:
>
> On Oct 5, 2012, at 10:08 AM, John Baldwin wrote:
>
> > On Thursday, October 04, 2012 1:20:52 pm Carl Delsey wrote:
> >> I noticed that the bus_space_*_8 functions are unimplemented for x86.
> >> Looking at the code, it seems this is i
Nikolay Denev wrote:
> On Oct 4, 2012, at 12:36 AM, Rick Macklem
> wrote:
>
> > Garrett Wollman wrote:
> >> < >> said:
> >>
> Simple: just use a sepatate mutex for each list that a cache
> entry
> is on, rather than a global lock for everything. This would
> reduce
> the
On Oct 8, 2012, at 3:21 AM, Wojciech Puchar wrote:
>> Not necessarily. If I understand correctly what Tim means, he's talking
>> about an in-memory compression of several blocks by several separate
>> threads, and then - after all the threads have compressed their
>
> but gzip format is single
13 matches
Mail list logo
