On Wed, Oct 28, 2009 at 08:59:15AM +0100, casper....@sun.com wrote: > > >On Tue 27 Oct 2009 at 10:58AM, Edward Pilatowicz wrote: > >> hey all, > >> > >> i have an updated webrev for my previous fix: > >> > >> http://cr.opensolaris.org/~edp/onnv-zmount/ > >> 6889379 zoneadm mount fails on opensolaris > >> 6894901 zoneadmd can hang if fdetach() return EBUSY > >> > >> you'll notice i added 6894901 to the fix. i hit this issue while doing > >> regression testing with the zones test suite. i've run the zones test > >> suite with these changes and verified that there are no new regressions. > > > >zoneadm.c:5655: system's > > > >zoneadmd.c: 2065: so, do you want to back off at all here? maybe > >sleep for a tenth of a second? Even with the yield, this will > >suck a lot of cpu if we get stuck in this forever. > > > Agreed; yield() should not be used at all in a loop (or perhaps never: you > should assume that yield() is a no-op). Specifically, it may cause the > CPU to run at the highest frequency. > > (poll(NULL, 0, 100); sleeps 0.1 second) >
please see my other email. this code is only invoked when zoneadmd is exiting because a zone is halting. it's a rare case. also, zoneadm is very aggressive in calling zoneadmd. it can invokes door calls in a loop. so in this case we WANT to be aggressive. we WANT to exit ASAP. if we had fast cpus and zoneadm can call into the door faster than every .1 seconds, polling won't work. yield() really is the right solution here. (yield() is not a no-op. it's unschedule me so someone else can run. thats exactly the semantic we want here.) i don't think poll() is a good option here. the other alternatives are: - redesign the exit dance between zoneadm and zoneadmd - just exit without bothering to fdetach() the door and let any subsequent zoneadmd instance deal with the need to fdetach(). ed _______________________________________________ zones-discuss mailing list zones-discuss@opensolaris.org
