On Sun, Nov 07, 2010 at 01:46:06PM +1100, Simon Burge wrote:
Masao Uebayashi wrote:
Module Name:src
Committed By: uebayasi
Date: Sat Nov 6 16:36:27 UTC 2010
Modified Files:
src/sys/arch/powerpc/ibm4xx: pmap.c
On Mon, Nov 08, 2010 at 06:09:39PM +, Antti Kantee wrote:
Modified Files:
src/sys/arch/mips/mips: locore_mips1.S
Log Message:
In TLBRead, restore PID before doing the saves so that the caller's
TLB entries are used instead of the PID given as the argument.
from
On Mon Nov 08 2010 at 21:40:49 +, David Holland wrote:
On Mon, Nov 08, 2010 at 06:09:39PM +, Antti Kantee wrote:
Modified Files:
src/sys/arch/mips/mips: locore_mips1.S
Log Message:
In TLBRead, restore PID before doing the saves so that the caller's
TLB entries are
The root cause of such a problem is, we don't do I/O scheduling at all.
I think that pool(9) (and pool_cache(9)) is a great tool to manage
limited resources. The way to go would be to extend it to manage
bandwidth in I/O subsystems. (We already use pool_cache(9) for
KVA.)
Resources are shared,
David Holland wrote:
On Mon, Nov 08, 2010 at 06:09:39PM +, Antti Kantee wrote:
Modified Files:
src/sys/arch/mips/mips: locore_mips1.S
Log Message:
In TLBRead, restore PID before doing the saves so that the caller's
TLB entries are used instead of the PID given as the
The first step would be to analyze code, identify glocal resource
allocations, and replace them to local ones. m_get() / m_clget()
would become per-socket, by allocating per-socket pool_cache.
On Tue, Nov 09, 2010 at 12:36:16PM +0900, Masao Uebayashi wrote:
The root cause of such a problem is,
