Re: emap
On Mon, 5 Dec 2011 04:19:13 + (UTC) y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote: > > Although I didn't think it'd be necessary to say so until this point, I > > admit that I myself didn't really understand what Takashi said about > > recommending amd64 over i386. If the hardware is 32-bit, or on > > constrained memory devices, i386 definitely needs to be supported. > > it isn't my recommendation. rmind@'s. Sorry about that, I should have rechecked upthread instead of looking at the quoting mess :) -- Matt
Re: emap
hi, > On Fri, 25 Nov 2011 23:25:24 +0400 > Aleksej Saushev wrote: > >> Thor Lancelot Simon writes: >> >> > On Fri, Nov 25, 2011 at 12:50:58PM +0400, Aleksej Saushev wrote: >> >> Mindaugas Rasiukevicius writes: >> >> >> >> > y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote: >> >> >> hi, >> >> >> >> >> >> what's the status of emap and pipe? >> >> >> >> >> > >> >> > ... and encourage our users to use amd64 instead >> >> > of i386. >> >> >> >> I'm sorry to intervene, what about WINE? Unless we're going to have it >> >> functional on amd64, encouraging is useless. >> > >> > I don't understand your comment. Are you suggesting that a large fraction >> > of >> > NetBSD/i386 users use WINE and therefore would not be able to switch to the >> > amd64 port? >> >> I mean that those users who could switch most probably have switched already. >> And one of serious reasons to stay on i386 is functional WINE. > > Although I didn't think it'd be necessary to say so until this point, I > admit that I myself didn't really understand what Takashi said about > recommending amd64 over i386. If the hardware is 32-bit, or on > constrained memory devices, i386 definitely needs to be supported. it isn't my recommendation. rmind@'s. YAMAMOTO Takashi > > But then again, I'm not familiar with the emap code; from the bits I > read in this thread, it could serve to optimize pipes? That pipes can > be better optimized on amd64 than on i386 is no problem to me, so I > assumed that he was talking about encouraging users to use amd64 if > they want to take advantage of a particular feature, not that i386 > would get deprecated and start to become unsupported. > > It would be nice if someone who knows better could explain better what > was meant, or confirm what I said above (if I understood correctly), > considering that it caused some worries... > > Thanks, > -- > Matt
Re: emap
hi, > Thor Lancelot Simon writes: > >> On Fri, Nov 25, 2011 at 12:50:58PM +0400, Aleksej Saushev wrote: >>> Mindaugas Rasiukevicius writes: >>> >>> > y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote: >>> >> hi, >>> >> >>> >> what's the status of emap and pipe? >>> >> >>> > >>> > ... and encourage our users to use amd64 instead >>> > of i386. >>> >>> I'm sorry to intervene, what about WINE? Unless we're going to have it >>> functional on amd64, encouraging is useless. >> >> I don't understand your comment. Are you suggesting that a large fraction of >> NetBSD/i386 users use WINE and therefore would not be able to switch to the >> amd64 port? > > I mean that those users who could switch most probably have switched already. > And one of serious reasons to stay on i386 is functional WINE. as we now have non-stack-based pthread_self (thanks joerg), porting the recent versions of wine should not be too hard. does it help wine on amd64? YAMAMOTO Takashi > > > -- > HE CE3OH...
Re: secmodel_register(9) API
hi,
> On Tue, 29 Nov 2011 11:13:01 + (UTC), y...@mwd.biglobe.ne.jp wrote:
>>> Reviews before merge welcome. If nobody raises his voice, I'll
>>> proceed
>>> to commit it at the end of the week.
>>
>> i hesitate to complicate kauth related locking rules, given that it's
>> already broken. have you checked if it's safe for these listeners
>> sleep?
>> (rw_enter can sleep.)
>
> I would say yes; the current patch uses secmodel_eval(9) for "curtain"
> mode, and its only applicable to kauth(9) listeners for:
> - socket "cansee" KAUTH_REQ_NETWORK_SOCKET_CANSEE
> - process KAUTH_REQ_PROCESS_CANSEE_{ARGS,ENTRY,OPENFILES}.
>
> All these listeners should have process context, so may sleep.
>
> Perhaps I can put pserialize(9) to good use there. Updates to
> secmodel(9) are not expected to happen that much often... You want me to
> have a look? That would make it lock-free even from softints.
if you are interested in, please.
see XXX in kauth_authorize_action_internal.
>
>> i thought the purpose of these secmodels are localize the knowledge
>> of
>> suser, securelevel, etc. secmodel_eval seems contradict.
>
> Exactly, that's the point. See below.
>
>> if anyone outside of the securelevel secmodel really needs to query
>> securelevel, doesn't it mean the variable just ought to be exported
>> in a normal way?
>
> "normal way" is quite difficult to define in the context of modules
> dynamic loading.
>
> Consider user_set_cpu_affinity: if the sysctl cannot be set any more
> when securelevel is above or below a threshold, checking for the
> securelevel variable means that this sysctl has a strong dependency on
> securelevel (or else, it won't be able to get the variable). So if you
> want to still provide this sysctl but without having securelevel loaded,
> you are screwed: it's part of this module.
>
> There are orthogonal requirements there: secmodels define a security
> policy, but there are situations where one would like to allow certain
> operations (different from default policy), but without putting a strong
> requirement on a specific secmodel(9). having to load securelevel just
> to provide this sysctl is non sense.
i don't understand the example.
your diff doesn't seem to do secmodel_eval("securelevel") at all.
>
> Same goes for suser (which controls rights for superuser):
> curtain/usermounts are not really a suser policy, rather an extension
> from it. Hence the secmodel_extensions stuff.
i don't understand what would be a suser policy and what would be an extension.
can you explain your criteria?
YAMAMOTO Takashi
>
> --
> Jean-Yves Migeon
> jeanyves.mig...@free.fr
Re: O->A loan
hi, > On Tue, Nov 29, 2011 at 06:38:27AM +, YAMAMOTO Takashi wrote: >> O->A loaned pages installed on the user address space would have a different >> owner than the usual map->entry.uvm_obj. >> although it was not a problem when you wrote this patch, at least some >> non-mechanical changes would be required after the recent locking >> changes in this area. namely, uvm_map_lock_entry etc now assumes that >> any pages mapped in a map entry belong to either the entry's amap or >> underlying object. > > ok, I didn't think it would be entirely mechanical. :-) > > what if the O->A loan code also changed the entry's uvm_obj to be the vnode > that the pages really belong to? if the loan range in the amap is fully > populated (which it is in this context) then that shouldn't affect the > logical contents of the entry, it would just cause anyone locking the entry > to also lock the vnode. if the range of the loan is smaller than the > range of the entry, we could split the entry. do you think that would work? it might work, but i have some concerns: - entry fragmentation - the extra uobj reference keeps the file even after unlink YAMAMOTO Takashi > > -Chuck
Re: O->A loan
hi, > On Mon, Nov 28, 2011 at 03:45:53AM +, YAMAMOTO Takashi wrote: >> hi, >> >> > On Sun, Nov 20, 2011 at 06:52:10PM +, YAMAMOTO Takashi wrote: >> >> hi, >> >> >> >> i'd like to to either fix or remove O->A page loaning. >> >> >> >> the biggest problem is the lack of users. thus no way to test. >> >> any ideas? >> > >> > some years ago I wrote some prototype code to use the O->A loaning for >> > read() and write(). the read() side worked, I don't think I had tested >> > the write() side so it probably has problems. the patch is still around: >> > ftp://ftp.netbsd.org/pub/NetBSD/misc/chs/diff.uvm_readloan.8 >> > >> > it's quite a bit out of date, but I think most of the changes needed >> > to update it would be mechanical. >> >> i'll take a look. thanks. >> >> did it (at least the read() side) have actual performance benefit >> compared to dumb copying? > > it helped quite a lot, yes. here's the email thread: > http://mail-index.netbsd.org/tech-kern/2005/02/15/0021.html thanks. it seems that i've read the thread. :-) what is the "pt" command used in the benchmark? does it break loans? YAMAMOTO Takashi > > -Chuck
Re: O->A loan
On Sun, Dec 04, 2011 at 06:04:59AM -0800, Chuck Silvers wrote: > > to also lock the vnode. if the range of the loan is smaller than the > range of the entry, we could split the entry. do you think that would work? Won't the range of the loan almost always be smaller than the range of the entry? Imagine reading through a 1MB file with 8K I/O requests. That'll be 128 splits (and 128 merges, if the intent is to merge afterwards), won't it? Thor
Re: O->A loan
On Tue, Nov 29, 2011 at 06:38:27AM +, YAMAMOTO Takashi wrote: > O->A loaned pages installed on the user address space would have a different > owner than the usual map->entry.uvm_obj. > although it was not a problem when you wrote this patch, at least some > non-mechanical changes would be required after the recent locking > changes in this area. namely, uvm_map_lock_entry etc now assumes that > any pages mapped in a map entry belong to either the entry's amap or > underlying object. ok, I didn't think it would be entirely mechanical. :-) what if the O->A loan code also changed the entry's uvm_obj to be the vnode that the pages really belong to? if the loan range in the amap is fully populated (which it is in this context) then that shouldn't affect the logical contents of the entry, it would just cause anyone locking the entry to also lock the vnode. if the range of the loan is smaller than the range of the entry, we could split the entry. do you think that would work? -Chuck
Re: O->A loan
On Mon, Nov 28, 2011 at 03:45:53AM +, YAMAMOTO Takashi wrote: > hi, > > > On Sun, Nov 20, 2011 at 06:52:10PM +, YAMAMOTO Takashi wrote: > >> hi, > >> > >> i'd like to to either fix or remove O->A page loaning. > >> > >> the biggest problem is the lack of users. thus no way to test. > >> any ideas? > > > > some years ago I wrote some prototype code to use the O->A loaning for > > read() and write(). the read() side worked, I don't think I had tested > > the write() side so it probably has problems. the patch is still around: > > ftp://ftp.netbsd.org/pub/NetBSD/misc/chs/diff.uvm_readloan.8 > > > > it's quite a bit out of date, but I think most of the changes needed > > to update it would be mechanical. > > i'll take a look. thanks. > > did it (at least the read() side) have actual performance benefit > compared to dumb copying? it helped quite a lot, yes. here's the email thread: http://mail-index.netbsd.org/tech-kern/2005/02/15/0021.html -Chuck
