Re: CVS commit: src/sys/uvm
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 VIPT design. So far OS > >>virtual memory strategy paid little attention to make VIPT cache work > >>correctly. > > > >It'd be nice if we can really eliminate VIPT fixup *code* in pmaps. > > > >And I *think* this is possible if we don't remap pages using > >pmap_kenter_pa(). > > The VIPT rule is simple; just make sure to match colour between > VPN and PFN. It's the mandatory programming practice. This rule > is clearly documented in _many_ CPU architecture documents with > VIPT cache. > > - mmap(2) must refuse to map mixed colour VA. Hmmm. I've thought that the page colouring constraint is *should*, not *must*. If it is really a must, yes, it's only the problem that how to achieve that in UVM. And UBC and other remapping methods (if exists) should make sure the rule. > - dynamic linker should pay attention to map share library at > "colour boundary." This ensure cache lines shared between > processes. > > Toru Nishimura / ALKYL Technology
Re: CVS commit: src/sys/uvm
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 index is selected for given a physical address. Consider the reason why VIPT alias issue vanishes when PAGE_SIZE is increased. It would make the number of colour into one _by_matching_ low order bits (= colour selector field) of VPN and PFN. Toru Nishimura / ALKYL Technology
Re: CVS commit: src/sys/uvm
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 reference is the first step. This only
> >> changes uvm_page_physload() to return a pointer:
> >>
> >>-void uvm_page_physload();
> >>+void *uvm_page_physload();
> >>
> >> But this makes XIP pager MUCH cleaner. The reason has been explained
> >> many times.
>
> because the separate uvm_page_physload_device is no longer necessary,
> you mean? i have no problem with the step.
>
> >> Making fault handlers and pagers to use vm_physseg * + off_t is
> >> the next step, and I don't intend to work on it now. I just want
> >> to explain the big picture.
> >>
> >> >
> >> > >>
> >> > >> Keep vm_physseg * + off_t array on stack. If UVM objects uses
> >> > >> vm_page (e.g. vnode), its pager looks up vm_page -> vm_physseg *
> >> > >> + off_t *once* and cache it on stack.
> >> >
> >> > do you mean something like this?
> >> > struct {
> >> > vm_physseg *hoge;
> >> > off_t fuga;
> >> > } foo [16];
> >>
> >> Yes.
> >>
> >> Or cache vm_page * with it, like:
> >>
> >>struct vm_id {
> >>vm_physseg *seg;
> >>off_t off;
> >>vm_page *pg;
> >>};
> >>
> >>uvm_fault()
> >>{
> >>vm_id pgs[];
> >>:
> >>}
> >>
> >> Vnode pager (genfs_getpages) takes vm_page's by looking up
> >> vnode::v_uobj's list, or uvn_findpages().
> >>
> >> When it returns back to fault handler, we have to lookup vm_physseg
> >> for each page. Then fill the "seg" slot above (assuming we'll
> >> remove vm_page::phys_addr soon).
> >>
> >> Fault handler calls per-vm_page operations iff vm_page slot is filled.
> >> XIP pages are not pageq'ed.
>
> pgo_get returns either seg+off or pg for each vm_id slots?
vm_id[] is passed to pgo_get, each pgo_get (uvn_get, udv_get, ...)
will fill seg + off and return the array back to uvm_fault.
Pagers that use vm_page (e.g. vnode) will get pg from vnode, then
lookup seg+off, fill them into the vm_id slot.
Those that don't use vm_page (e.g. cdev) will get seg+off from
underlying objects, fill them into the vm_id slot, and return.
>
> >> XIP pages don't need vm_page, but
> >> cached because it's vnode.
>
> can you explain this sentence?
Sorry, it was so unclear.
XIP pages don't need vm_page (as a paging state variable),
because the pages are read-only and never involve paging.
XIP pages have to be mapped as cacheable at MMU level,
because it's vnode.
I'm allocating the full vm_page for XIP'able pages, only because
chs@ wanted to support loaning, which needs vm_page::loan_count.
>
> >> (Just in case, have you read my paper?)
>
> which paper? i guess no.
http://uebayasi.dyndns.org/~uebayasi/tmp/xip.pdf
>
> YAMAMOTO Takashi
--
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635
Re: CVS commit: src/sys/uvm
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. -> just make sure to choose a matched va. -> for example, vmapbuf() is responsible to do it right. Infamous "SOSEND_NO_LOAN" option fails into the second case. ipc_socket.c is apparently ignorant about KVA colour matching. It ends up with potential VIPT alias by choosing conflicting KVA to make double map. The most common usage of mmap(2) is like; va = mmap((void *)0, ... ); Kernel is free to choose and return va which fits at "colour boundary." If conflicting va is given in the 1st argument, mmap neglects the hint value and choose matched va which may or may not be close to the hint. 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 system, determine the number of colour from cache size and way count to tell. No pmap fixup code is necessary. I would emphasis here that whole VIPT issue lies in MI part of VM, which is unware of colour match scheme and makes VIPT alias by itself, not in VM MD part. Toru Nishimura / ALKYL Technology
Re: CVS commit: src/sys/uvm
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 for PIPT systems (to make better use of caches), just in a sighly different way. I think the MI VM system should be made aware of the cache type and select is behavior (i.e. use colours only for PA allocation, or VA+PA allocations) based on this. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: /var/lock
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 and other tools. >> >Change group owner to operator to enable LVM locking for him. >> >> Why is /var/run not the right place for your needs? > > Also, where was this discussed? If it was discussed, please > update hier(7) according to the outcome of the discussion. Ok I have commited fix for this. lvm tools now use /var/run/lvm directory for locks. I have patched mountcritlocal to create this dir for us, that wya it works for everyone in every case. -- Regards. Adam
Re: CVS commit: src/tests/sbin/resize_ffs
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 bonus, however, 'seq' is actually a better fit (the commandline is > more intuitive) for the way it is used in these tests. I agree that "jot $(($2-$1+1)) $1" is ugly, but there was no need for that ugliness; a cleaner way to ask jot to output values from $1 to $2 in steps of 1 is "jot - $1 $2 1". I have added an example to the jot(1) man page. --apb (Alan Barrett)
Re: CVS commit: src/tests/fs/common
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 is r/o and > does the actual testing. Also, introduce a nfsro fstype which does > a clientside r/w mount for a r/o server export. > > requested by yamt thanks. > (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 distinguish EROFS and EACCES. ie. EACCES is the expected behaviour in this case. YAMAMOTO Takashi > > > To generate a diff of this commit: > cvs rdiff -u -r1.23 -r1.24 src/tests/fs/common/h_fsmacros.h > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files.
re: CVS commit: src/sys/arch/ofppc/conf
> 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 in GENERIC kernel. .mrg.
Re: /var/lock
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). > Creating lvm subdir beneath is (owned by operator) feels monumentally > gross. Bleh. Yeah, ok, I dunno then. Adding /var/lock seems like a decent approach (and maybe we should get rid of /var/spool/lock, since we removed base uucp quite a whle back...) -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/tests/fs/common
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 distinguish EROFS and EACCES. ie. EACCES is > the expected behaviour in this case. Shouldn't the nfs client know that it's supposed to be readonly? Or is this a case where the nfs client is read-write but the server isn't? -- David A. Holland dholl...@netbsd.org
