public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Re: Does the kernel page the CFS's red-black tree nodes?
       [not found] <AANLkTilfw_rXQ4P1jRnrOtun2c9kAq6zNEQHxTF124_x@mail.gmail.com>
@ 2010-06-16  0:55 ` Richard Yao
  2010-06-16 11:15   ` Alan Cox
  2010-06-17  8:04   ` Andi Kleen
  0 siblings, 2 replies; 3+ messages in thread
From: Richard Yao @ 2010-06-16  0:55 UTC (permalink / raw)
  To: linux-kernel

Dear Linus Torvalds et all:

I read a recently published article on the ACM website, which
discusses the effect virtual memory pressure has on certain algorithms
and explains that data structures need to be designed in such a way
that they minimize such effects:

http://queue.acm.org/detail.cfm?id=1814327

The author observed slow-downs in an algorithm that ignored virtual
memory upon the incidence of page faults. The basic idea I took from
it is that people should use B-Heaps instead of Binary Heaps and
B-Trees instead of Binary Trees for optimal performance on modern
systems that use virtual memory. Today, it occurred to me that the
kernel's completely fair scheduler could be susceptible this sort of
slow-down, provided that the kernel pages its red-black tree nodes to
swap, so I thought I would ask here if this is the case.

With that said, does the kernel page the CFS's red-black tree nodes to
swap? If it does, it might be a good idea to reimplement the CFS'
Red-Black trees in B-Trees, which would minimize slow-downs from
vm-pressure and also have the additional benefit of minimizing cache
misses caused by tree traversal.

This is my first post to the kernel mailing list. The FAQ says that I
should indicate that I "wish to be personally CC'ed the
answers/comments posted to the list in response" to my posting, so
this sentence is my indication that I "wish to be personally CC'ed the
answers/comments posted to the list".

Yours truly,
Richard Yao

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Does the kernel page the CFS's red-black tree nodes?
  2010-06-16  0:55 ` Does the kernel page the CFS's red-black tree nodes? Richard Yao
@ 2010-06-16 11:15   ` Alan Cox
  2010-06-17  8:04   ` Andi Kleen
  1 sibling, 0 replies; 3+ messages in thread
From: Alan Cox @ 2010-06-16 11:15 UTC (permalink / raw)
  To: Richard Yao; +Cc: linux-kernel

The kernel doesn't page its own data structures (there a couple of
exceptional cases). That avoids the entire nightmare of trying to have
partly paged kernels, the resulting priority inversions and all the other
horrors you can get plus the big overheads from it.

Alan

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Does the kernel page the CFS's red-black tree nodes?
  2010-06-16  0:55 ` Does the kernel page the CFS's red-black tree nodes? Richard Yao
  2010-06-16 11:15   ` Alan Cox
@ 2010-06-17  8:04   ` Andi Kleen
  1 sibling, 0 replies; 3+ messages in thread
From: Andi Kleen @ 2010-06-17  8:04 UTC (permalink / raw)
  To: Richard Yao; +Cc: linux-kernel

Richard Yao <shiningarcanine@gmail.com> writes:
>
> With that said, does the kernel page the CFS's red-black tree nodes to
> swap? If it does, it might be a good idea to reimplement the CFS'
> Red-Black trees in B-Trees, which would minimize slow-downs from
> vm-pressure and also have the additional benefit of minimizing cache
> misses caused by tree traversal.

The kernel does not swap itself, but yes in theory btrees might help to 
improve CPU cache locality.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2010-06-17  8:05 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <AANLkTilfw_rXQ4P1jRnrOtun2c9kAq6zNEQHxTF124_x@mail.gmail.com>
2010-06-16  0:55 ` Does the kernel page the CFS's red-black tree nodes? Richard Yao
2010-06-16 11:15   ` Alan Cox
2010-06-17  8:04   ` Andi Kleen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox