Re: lwp resource limit
On Jun 4, 2012, at 7:19 PM, Christos Zoulas wrote: In article 20120605013242.ga7...@panix.com, Thor Lancelot Simon t...@panix.com wrote: On Mon, Jun 04, 2012 at 06:13:09PM -0400, Christos Zoulas wrote: That is a good idea! The only problem with it is that ps -sx and the sysctl limit will not match (the limit will be lower than the sysctl number by the number of processes). It does have the nice property though that the process gets created anyway, as it is now (counting the limit). It is a very simple change, and if people prefer it, I will do it. I think it's truly elegant. Do it! I'll need to burn a bit in the lwp flags to indicate that exit should not decrease the count, or hardcode not to do it for lid == 1. Which one do you prefer? The latter is my preference. How many processes ever have lid 1 exit early?
Re: lwp resource limit
On Mon, Jun 04, 2012 at 11:16:45PM -0700, Matt Thomas wrote: The latter is my preference. How many processes ever have lid 1 exit early? Yes, do not count lid 1 and don't have it decrement the count on exit. Martin
Re: lwp resource limit
On Tue, Jun 05, 2012 at 11:20:35AM +0200, Martin Husemann wrote: On Mon, Jun 04, 2012 at 11:16:45PM -0700, Matt Thomas wrote: The latter is my preference. How many processes ever have lid 1 exit early? Yes, do not count lid 1 and don't have it decrement the count on exit. some processes (ie. emul_linux ones) do not have a lid 1, so this won't work. can't you just not change the count for the last lwp in a process? -Chuck
pmap fragmentation
If you look at the pmap(1) output for something like firefox on amd64 you see: 0040 36K read/exec /usr/pkg/lib/xulrunner/xulrunner-bin 00609000 4K read/write [ anon ] 7F7FC040 64K read/write [ anon ] 7F7FC041960K read/write [ anon ] 7F7FC050 64K read/write [ anon ] 7F7FC051960K read/write [ anon ] 7F7FC060 64K read/write [ anon ] 7F7FC061960K read/write [ anon ] ... About 1000 on the 1300 lines are read/write anon (presumably mmap() by the malloc code?) and they are in large blocks of adjacent entries. Surely it would be better to merge these entries (or rather, create them by extending the previous one)? There has to be code to split entries during unmap - as it is valid to unmap the middle of a mapped area. So ansty effects are unlikely. David -- David Laight: da...@l8s.co.uk
Devices not at mainbus?
Aside from pseudodevices, do we have any devices which aren't children of mainbus? Some ports' use of obio seems like, perhaps, a candidate for this, but I have not started checking them all. -- Thor Lancelot Simont...@panix.com We cannot usually in social life pursue a single value or a single moral aim, untroubled by the need to compromise with others. - H.L.A. Hart
Re: Devices not at mainbus?
On Jun 5, 2012, at 8:42 AM, Thor Lancelot Simon wrote: Aside from pseudodevices, do we have any devices which aren't children of mainbus? Some ports' use of obio seems like, perhaps, a candidate for this, but I have not started checking them all. directly or through parents? Not all ports use mainbus. shark uses ofbus at root (only cpu attaches to mainbus).
Re: Devices not at mainbus?
On Tue, Jun 05, 2012 at 08:52:38AM -0700, Matt Thomas wrote: On Jun 5, 2012, at 8:42 AM, Thor Lancelot Simon wrote: Aside from pseudodevices, do we have any devices which aren't children of mainbus? Some ports' use of obio seems like, perhaps, a candidate for this, but I have not started checking them all. directly or through parents? Through parents. I'm looking at trying to inherit maxphys down the device tree. Not all ports use mainbus. shark uses ofbus at root (only cpu attaches to mainbus). Oof. That's the answer, then, I guess. -- Thor Lancelot Simont...@panix.com We cannot usually in social life pursue a single value or a single moral aim, untroubled by the need to compromise with others. - H.L.A. Hart
re: merge coming soon: jmcneill-usbmp
- usbd_bus_methods{} gains a get_lock() to enable the
host controller to provide a lock for the USB code.
if the lock isn't provided, old-style protection is
(partially) applied.
It is better if the USB driver can select the lock, like in FreeBSD. Else you
run into some atomic races when two SMP'enabled stacks are talking to
eachother, like a SMP-CAM layer and a SMP-USB stack.
can you expand a little on what sort of races you mean? for me, i
originally helped with this effort so we could talk to the recently
commited MP audio stack.
Has the FreeBSD's USB stack been evaluated when doing this NetBSD smp-ng, or
is this just a simple effort to try to get things a bit better than is now?
the latter. i'm not a USB person, and didn't really expect to come
the owner of this project when i started helping :) the TODO.usbmp
has quite a few non trivial items in it, but those are more about
enabling device-specific MP support at this point.
thanks.
.mrg.
Re: Devices not at mainbus?
On Tue, Jun 05, 2012 at 12:03:49PM -0400, Thor Lancelot Simon wrote: Aside from pseudodevices, do we have any devices which aren't children of mainbus? Some ports' use of obio seems like, perhaps, a candidate for this, but I have not started checking them all. directly or through parents? Through parents. I'm looking at trying to inherit maxphys down the device tree. Not all ports use mainbus. shark uses ofbus at root (only cpu attaches to mainbus). Oof. That's the answer, then, I guess. Does it matter? Is there a case where a driver's notion of MAXPHYS should depend on anything other than the buses it's attached to? -- David A. Holland dholl...@netbsd.org
Re: Devices not at mainbus?
On Tue, Jun 05, 2012 at 06:06:08PM +, David Holland wrote: Does it matter? Is there a case where a driver's notion of MAXPHYS should depend on anything other than the buses it's attached to? I see you say buses. So I assume you're taking into account funny constraints to do with bus bridges. Some ports do have limits stricter than those actually associated with any physical bus in the machine. Xen is a good example. Thor
Re: Devices not at mainbus?
On Tue, Jun 05, 2012 at 02:14:02PM -0400, Thor Lancelot Simon wrote: Does it matter? Is there a case where a driver's notion of MAXPHYS should depend on anything other than the buses it's attached to? I see you say buses. So I assume you're taking into account funny constraints to do with bus bridges. Yes. Some ports do have limits stricter than those actually associated with any physical bus in the machine. Xen is a good example. ah, and then the question is where to manifest those. right... -- David A. Holland dholl...@netbsd.org
Re: merge coming soon: jmcneill-usbmp
On Tuesday 05 June 2012 19:59:08 matthew green wrote:
- usbd_bus_methods{} gains a get_lock() to enable the
host controller to provide a lock for the USB code.
if the lock isn't provided, old-style protection is
(partially) applied.
It is better if the USB driver can select the lock, like in FreeBSD. Else
you run into some atomic races when two SMP'enabled stacks are talking
to eachother, like a SMP-CAM layer and a SMP-USB stack.
Hi,
can you expand a little on what sort of races you mean? for me, i
originally helped with this effort so we could talk to the recently
commited MP audio stack.
I can try to explain it a bit short.
If two SMP enabled stacks have each their lock, and they are calling each
other, that means any callbacks must go unlocked, because else you can get a
LOR (locking order reversal). Agree?
USB allows transactions to be cancelled. How can you exclude a callback from
executing when it is being cancelled? Maybe you need one non-blocking cancel
and a blocking cancel. Only the blocking cancel is allowed to wait for other
threads to finish, and this is not the problem. The non-blocking version would
need to do this by locking a non-sleepable mutex, and this is when the
problems and possible races start.
For example in case of fast open/close of character devices like /dev/ulptX,
what will happen if a USB transfer is started and stopped in a loop really
quick, assuming you don't allocate new transfers, but reuse existing ones.
Will the USB stack handle the calls so that the last call is the winning one?
Or will the output be random?
Has the FreeBSD's USB stack been evaluated when doing this NetBSD smp-ng,
or is this just a simple effort to try to get things a bit better than
is now?
the latter. i'm not a USB person, and didn't really expect to come
the owner of this project when i started helping :) the TODO.usbmp
has quite a few non trivial items in it, but those are more about
enabling device-specific MP support at this point.
--HPS
Re: Devices not at mainbus?
On Tue, Jun 05, 2012 at 02:14:02PM -0400, Thor Lancelot Simon wrote: On Tue, Jun 05, 2012 at 06:06:08PM +, David Holland wrote: Does it matter? Is there a case where a driver's notion of MAXPHYS should depend on anything other than the buses it's attached to? I see you say buses. So I assume you're taking into account funny constraints to do with bus bridges. Some ports do have limits stricter than those actually associated with any physical bus in the machine. Xen is a good example. Actually, anything that has a MAXPHYS restriction in Xen attaches to hypervisor. So hypervisorbus could set the property ... -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
