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
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 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 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 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 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) ==
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
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
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
>>>
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
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
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
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
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
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
;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
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
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
18 matches
Mail list logo
