On Wed, Sep 29, 2010 at 01:22:56PM -0700, Matthew Fleming wrote:
> On Wed, Sep 29, 2010 at 1:12 PM, Kostik Belousov 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 into addres
On Tue, Sep 21, 2010 at 7:38 PM, Alan Cox wrote:
> On Mon, Sep 20, 2010 at 9:32 AM, Svatopluk Kraus 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 used (for example 'kmem_alloc_n
;ve hacked up a crude and somewhat
mechanical patch to convert the vmmap and page VM 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.di
s for its internal housekeeping. RB tree details:
> http://en.wikipedia.org/wiki/Red-black_tree
>
> I say hypothesis because I haven't measured the difference to an
> RB tree implementation yet. I've hacked up a crude and somewhat
> mechanical patch to convert the vmmap
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 whet
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 tree
y can be done
> with standard RB tree accessors. Our standard userspace jemalloc
> also uses RB trees for its internal housekeeping. RB tree details:
> http://en.wikipedia.org/wiki/Red-black_tree
>
> I say hypothesis because I haven't measured the difference to an
> RB tr
ough.
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 simplifications becoming possibl
On Thu, Sep 30, 2010 at 12:37 PM, Andre Oppermann 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 an interest
On 09/30/10 20:01, Alan Cox wrote:
> On Thu, Sep 30, 2010 at 12:37 PM, Andre Oppermann 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
>>>
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 mac
Our standard userspace jemalloc
> also uses RB trees for its internal housekeeping. RB tree details:
> http://en.wikipedia.org/wiki/Red-black_tree
>
> I say hypothesis because I haven't measured the difference to an
> RB tree implementation yet. I've hacked up a crude an
On Thu, Sep 30, 2010 at 10:17 AM, Andriy Gapon 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 sizeof(kmem_map->size) ==
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
on 30/09/2010 21:52 Garrett Cooper said the following:
> On Thu, Sep 30, 2010 at 10:17 AM, Andriy Gapon 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_si
On 30.09.2010 20:01, Alan Cox wrote:
On Thu, Sep 30, 2010 at 12:37 PM, Andre Oppermann 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
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 than
On Thu, Sep 30, 2010 at 1:26 PM, Andriy Gapon wrote:
> on 30/09/2010 21:52 Garrett Cooper said the following:
>> On Thu, Sep 30, 2010 at 10:17 AM, Andriy Gapon wrote:
>>>
>>> Here's a patch that adds a sysctl for querying kmem_map->size, which may be
>>> useful
>>> for system state/resources mon
18 matches
Mail list logo
