Dear all,
I would like to remind you that the next round of status reports
covering the third quarter of 2010 is due on October 15th, 2010. This
initiative is very welcome in our community. Therefore, I would like to
ask you to submit your status reports soon, so that we can compile the
report
On Wed, Sep 29, 2010 at 01:22:56PM -0700, Matthew Fleming wrote:
On Wed, Sep 29, 2010 at 1:12 PM, Kostik Belousov kostik...@gmail.com wrote:
On Wed, Sep 29, 2010 at 12:40:57PM -0700, Matthew Fleming wrote:
I'm hacking around with making a fast reboot that puts a copy of the
MBR from disk
On Tue, Sep 21, 2010 at 7:38 PM, Alan Cox alan.l@gmail.com wrote:
On Mon, Sep 20, 2010 at 9:32 AM, Svatopluk Kraus onw...@gmail.com wrote:
Beyond 'kernel_map', some submaps of 'kernel_map' (buffer_map,
pager_map,...) exist as result of 'kmem_suballoc' function call.
When this submaps are
structures to
use RB trees, the vmmap part is not stable yet. The page part
seems to work fine though.
This is what I've hacked together so far:
http://people.freebsd.org/~andre/vmmap_vmpage_stats-20100930.diff
http://people.freebsd.org/~andre/vmmap_vmpage_rbtree-20100930.diff
The diffs are still
://people.freebsd.org/~andre/vmmap_vmpage_stats-20100930.diff
http://people.freebsd.org/~andre/vmmap_vmpage_rbtree-20100930.diff
The diffs are still in their early stages and do not make use of
any code simplifications becoming possible by using RB trees instead
of the current splay trees.
Comments
Here's a patch that adds a sysctl for querying kmem_map-size, which may be
useful
for system state/resources monitoring:
http://people.freebsd.org/~avg/sysctl-kmem_map_size.diff
I am quite unsure about sizeof(kmem_map-size) == sizeof(int) hack, but I
couldn't
think of other way to decide
On 30.09.2010 18:37, Andre Oppermann wrote:
Just for the kick of it I decided to take a closer look at the use of
splay trees (inherited from Mach if I read the history correctly) in
the FreeBSD VM system suspecting an interesting journey.
Correcting myself regarding the history: The splay
part
seems to work fine though.
This is what I've hacked together so far:
http://people.freebsd.org/~andre/vmmap_vmpage_stats-20100930.diff
http://people.freebsd.org/~andre/vmmap_vmpage_rbtree-20100930.diff
The diffs are still in their early stages and do not make use of
any code
://people.freebsd.org/~andre/vmmap_vmpage_stats-20100930.diff
http://people.freebsd.org/~andre/vmmap_vmpage_rbtree-20100930.diff
The diffs are still in their early stages and do not make use of
any code simplifications becoming possible by using RB trees instead
of the current splay trees.
Comments on the VM
On Thu, Sep 30, 2010 at 12:37 PM, Andre Oppermann an...@freebsd.org wrote:
On 30.09.2010 18:37, Andre Oppermann wrote:
Just for the kick of it I decided to take a closer look at the use of
splay trees (inherited from Mach if I read the history correctly) in
the FreeBSD VM system suspecting
On 09/30/10 20:01, Alan Cox wrote:
On Thu, Sep 30, 2010 at 12:37 PM, Andre Oppermann an...@freebsd.org wrote:
On 30.09.2010 18:37, Andre Oppermann wrote:
Just for the kick of it I decided to take a closer look at the use of
splay trees (inherited from Mach if I read the history correctly)
Hi.
Karl Pielorz wrote:
I just switched my 8.1-R/amd64 (dual Opteron) system from ATA over to
the new mvs driver, and started seeing a whole bunch of errors (which
appear to have hosed one of my zfs volumes during a scrub) - anyone know
what the following errors actually mean?
The machine
together so far:
http://people.freebsd.org/~andre/vmmap_vmpage_stats-20100930.diff
http://people.freebsd.org/~andre/vmmap_vmpage_rbtree-20100930.diff
The diffs are still in their early stages and do not make use of
any code simplifications becoming possible by using RB trees instead
On Thu, Sep 30, 2010 at 10:17 AM, Andriy Gapon a...@icyb.net.ua wrote:
Here's a patch that adds a sysctl for querying kmem_map-size, which may be
useful
for system state/resources monitoring:
http://people.freebsd.org/~avg/sysctl-kmem_map_size.diff
I am quite unsure about
On 09/30/10 20:38, Alfred Perlstein wrote:
Andre,
Your observations on the effectiveness of the splay tree
mirror the concerns I have with it when I read about it.
I have always wondered though if the splay-tree algorithm
was modified to only perform rotations when a lookup required
more
on 30/09/2010 21:52 Garrett Cooper said the following:
On Thu, Sep 30, 2010 at 10:17 AM, Andriy Gapon a...@icyb.net.ua wrote:
Here's a patch that adds a sysctl for querying kmem_map-size, which may be
useful
for system state/resources monitoring:
On 30.09.2010 20:01, Alan Cox wrote:
On Thu, Sep 30, 2010 at 12:37 PM, Andre Oppermannan...@freebsd.org wrote:
On 30.09.2010 18:37, Andre Oppermann wrote:
Just for the kick of it I decided to take a closer look at the use of
splay trees (inherited from Mach if I read the history correctly)
On 30.09.2010 20:38, Alfred Perlstein wrote:
Andre,
Your observations on the effectiveness of the splay tree
mirror the concerns I have with it when I read about it.
I have always wondered though if the splay-tree algorithm
was modified to only perform rotations when a lookup required
more
On Thu, Sep 30, 2010 at 1:26 PM, Andriy Gapon a...@icyb.net.ua wrote:
on 30/09/2010 21:52 Garrett Cooper said the following:
On Thu, Sep 30, 2010 at 10:17 AM, Andriy Gapon a...@icyb.net.ua wrote:
Here's a patch that adds a sysctl for querying kmem_map-size, which may be
useful
for system
19 matches
Mail list logo
