Re: CVS commit: src/sys/uvm

2011-01-05 Thread Masao Uebayashi
On Wed, Jan 05, 2011 at 01:29:02AM +0900, Toru Nishimura wrote: > Masao Uebayashi responds as; > > >>The entire effect is to eliminate the necessity of VIPT fixup efforts in > >>port-specific pmap.c and ends up with improving the cache effeciency > >>in large degree. This is _the intent_ behind

Re: CVS commit: src/sys/uvm

2011-01-05 Thread Toru Nishimura
Masao Uebayashi responds as; The VIPT rule is simple; just make sure to match colour between VPN and PFN. Hmmm. I've thought that the page colouring constraint is *should*, not *must*. Colour match between VPN and PFN is *must* If not obeying the rule, it's possible two or more cache in

Re: CVS commit: src/sys/uvm

2011-01-05 Thread Masao Uebayashi
On Wed, Jan 05, 2011 at 05:58:34AM +, YAMAMOTO Takashi wrote: > hi, > > > I take silence as "no objection". > > the silence in this case means was-busy-for-other-things-and-forgot. > sorry. > > >> I have no real code for this big picture at this moment. Making > >> vm_physseg available as r

Re: CVS commit: src/sys/uvm

2011-01-05 Thread Toru Nishimura
Some more rambling commments; > Colour match between VPN and PFN is *must* There are two cases when colour match rule does matter; 1. new physical page is assigned for a given va. -> just make sure to choose matched PFN with VPN. 2. kernel double maps another va, which may be KVA or UVA.

Re: CVS commit: src/sys/uvm

2011-01-05 Thread Manuel Bouyer
On Thu, Jan 06, 2011 at 02:11:53AM +0900, Toru Nishimura wrote: > [...] > For each port, it's just ok to tell UVM the number of colour > at boot time. In PIPT system, the number is one, which > makes whole VM logic works just as before. In VIPT Not really, the number of coulours is also used fo

Re: /var/lock

2011-01-05 Thread haad
On Mon, Jan 3, 2011 at 1:21 PM, Alan Barrett wrote: > On Mon, 03 Jan 2011, rud...@eq.cz wrote: >> Adam Hamsik wrote: >> >Modified Files: >> >     src/distrib/sets/lists/base: mi >> >     src/etc/mtree: NetBSD.dist.base >> > >> >Log Message: >> >Add /var/lock directory to base set it's used by LVM

Re: CVS commit: src/tests/sbin/resize_ffs

2011-01-05 Thread Alan Barrett
On Wed, 05 Jan 2011, Jeff Rizzo wrote: > Modified Files: > src/tests/sbin/resize_ffs: common.sh > > Log Message: > Replace uses of 'jot' with 'seq'. This is primarily to work around > a qemu-running-on-netbsd problem with FP which causes 'jot' to output > incorrect sequences [...] > As a b

Re: CVS commit: src/tests/fs/common

2011-01-05 Thread YAMAMOTO Takashi
hi, > Module Name: src > Committed By: pooka > Date: Fri Dec 31 18:16:41 UTC 2010 > > Modified Files: > src/tests/fs/common: h_fsmacros.h > > Log Message: > Introduce r/o tests. They do two mounts: the first one is r/w and > runs a generator which primes the fs. The second one i

re: CVS commit: src/sys/arch/ofppc/conf

2011-01-05 Thread matthew green
> Module Name: src > Committed By: matt > Date: Mon Dec 20 00:14:41 UTC 2010 > > Modified Files: > src/sys/arch/ofppc/conf: GENERIC > > Log Message: > Add siisata (but make sure wd0 is still on viaide) i don't like this hack to "force" wd0 to viaide. it seems to be out of place

Re: /var/lock

2011-01-05 Thread David Holland
On Wed, Jan 05, 2011 at 02:09:16AM +0300, Valeriy E. Ushakov wrote: > > Anyway, the reason this whole thread started out with /var/lock is > > that the Linux world apparently also did this with /var/spool/lock. > > But our /var/spool/lock is specifically uucp's lockdir (uucp/daemon). > Creati

Re: CVS commit: src/tests/fs/common

2011-01-05 Thread David Holland
On Thu, Jan 06, 2011 at 12:53:28AM +, YAMAMOTO Takashi wrote: > > (one nfsro test currently fails with EROFS vs. EACCES. Hopefully > > someone else can debate the correct errno) > > the NFS ACCESS procedure, which is used for open time permission checks, > does not have a way to distingu