In this freebsd-hackers thread[1], a user reported that 10.1-RELEASE
crashes during boot on a system with 3TB of RAM. As it turns out, when you
have that much RAM ZFS autotunes itself to allocate a 6GB hash table. This
triggers a nasty 32-bit integer truncation bug in malloc(9). malloc()
calls u
[snip]
someone emailed me privately - no tracking/priority lending is
happening for readers. :(
-a
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-
Again, why's it not loaning priority to the lock-owning thread when
it's blocked? I thought that's what is supposed to happen.
-adrian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe
On Thu, Mar 12, 2015 at 1:36 PM, Mateusz Guzik wrote:
> Workloads like buildworld and the like (i.e. a lot of forks + execs) run
> into very severe contention in vm, which is orders of magnitude bigger
> than anything else.
>
> As such your result seems quite suspicious.
>
You're right, I did me
Hello,
I run HEAD i386 on an Acer C720 netbook (the so called Cromebook), which
works pretty much fine and very fast.
The device is used on a daily basis with 18++ hours uptime a day.
>From time to time (since January exactly 5 times) I faced a complete
randomly power-off of the device. Please,
