Re: cvs commit: src/sys/geom/eli g_eli.c

On Tuesday 30 January 2007 18:32, Pawel Jakub Dawidek wrote:
On Tue, Jan 30, 2007 at 04:36:36PM -0500, John Baldwin wrote:
On Monday 29 January 2007 15:19, Pawel Jakub Dawidek wrote:
I fully agree that there should be a clean KPI for this. What you
proposed if fine. Because of lack of such KPI geli has to handle HTT
CPUs which are turned off by default in releases also by abusing
scheduler internals. KPI you proposed would allow me to remove those
hacks. And I'm really all for it.

What you and Scott are missing is that when I implement a GEOM class,
I'm using what is available to do my work. I'm not going to educate
myself how schedulers work, implement nice and clean KPI to use it in
my class. I'm not saying it wouldn't be great to be able to do so, but I
don't have time for everything, unfortunately, and you guys should
understand that very well.

Something you seem to be missing though is that in general it's nice to
not
just endulge in an endless series of hacks in your specific area of the
system. IWBN to at some point devote some time to help fix more general
problems that will benefit the system as a whole rather than adding hacks
that just benefit yourself and require someone else to clean up when they
eventually add the more-architected solution. We are all very busy, but
if
everyone just did hacks and never put any effort into improving the
general
infrastructure, we'd have a royal mess.

To improve the infrastructure, one should feel strong about areas he
want to improve. I do infrastructual work in areas, where I think I've a
clue. Asking me to work on schedulers or SMP architecture where I don't
feel competent enough is just unfair, John. The time I need to spend on
educating myself in those areas will be much longer than I can afford.
So my choice is leave broken code and ignore the users, or fix it using
tools available now and fix it better when the infrastructure is ready
or I've time to work on the infrastructure in this area.
If someone competent will provide infrastructural improvements I can
use, I'd love to use it. I try hard not to leave my code behind.

Can we move on now?

I wouldn't sell yourself so short actually. :) You're probably more competent
than you think. I'm not really an expert on SMP or schedulers either (I've
not had any formal training, and if you were to review some of my earlier SMP
stuff it shows), but ended up working on it because it needed to be done.
Most of what I've learned is by just working on stuff. Anyways, maybe this
issue will bubble up to someone's todo list at BSDCan to settle how to handle
CPU's arriving and departing. One big thing that worries me is how to handle
pinned and bound threads when a CPU goes away. Also, it may be more useful
to think of CPUs not as just present/not present, but more in terms of:

- not present
- present but offline
- present and online

And most code would really only care about offline/online events. We could
maybe allow pinned and bound threads to still run on an offline CPU (and the
idlethread for that CPU of course) but require that there be no pinned bound
threads to completely detach a CPU (in the case of systems with removable
CPUs). It would be useful to at least handle taking CPUs offline and then
back online though.

--
John Baldwin
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: [PATCH] reduce inter-node balancing frequency
    ... > If there are, they should be based off the topo infrastructure, not static ... Apart from having to pull hot cachelines off 511 CPUs while in interrupt ... 64 CPUs into each top level domain). ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: The machdep.hyperthreading_allowed & ULE weirdness in 7.1
    ... but one question is how far to take it -- caches are shared to varying degrees at varying levels of the topology. ... However, I believe the recommendation has generally moved to disabling hyperthreading using the BIOS, as that uses the vendor's notion of hyperthreading. ... The idea of changing the setting at run-time is currently untenable because we don't have the OS infrastructure to take CPUs out of service, although growing it would be useful in order to support virtual machine dynamic CPU reconfiguration. ...
    (freebsd-stable)
  • Re: The machdep.hyperthreading_allowed & ULE weirdness in 7.1
    ... but one question is how far to take it -- caches are shared to varying degrees at varying levels of the topology. ... However, I believe the recommendation has generally moved to disabling hyperthreading using the BIOS, as that uses the vendor's notion of hyperthreading. ... The idea of changing the setting at run-time is currently untenable because we don't have the OS infrastructure to take CPUs out of service, although growing it would be useful in order to support virtual machine dynamic CPU reconfiguration. ...
    (freebsd-current)
  • Re: The machdep.hyperthreading_allowed & ULE weirdness in 7.1
    ... but one question is how far to take it -- caches are shared to varying degrees at varying levels of the topology. ... However, I believe the recommendation has generally moved to disabling hyperthreading using the BIOS, as that uses the vendor's notion of hyperthreading. ... The idea of changing the setting at run-time is currently untenable because we don't have the OS infrastructure to take CPUs out of service, although growing it would be useful in order to support virtual machine dynamic CPU reconfiguration. ...
    (freebsd-stable)
  • Re: The machdep.hyperthreading_allowed & ULE weirdness in 7.1
    ... but one question is how far to take it -- caches are shared to varying degrees at varying levels of the topology. ... However, I believe the recommendation has generally moved to disabling hyperthreading using the BIOS, as that uses the vendor's notion of hyperthreading. ... The idea of changing the setting at run-time is currently untenable because we don't have the OS infrastructure to take CPUs out of service, although growing it would be useful in order to support virtual machine dynamic CPU reconfiguration. ...
    (freebsd-current)