Bao, On Sun, 14 Nov 2004 14:41:34 +0800, Bao zhao <paozhaokeats@xxxxxxxxxxx> wrote: > I read articles from lwn.net. http://lwn.net/Articles/80911/ > It said: > " Note that, in the actual code, the hierarchy is represented a little > differently than has been portrayed above; each CPU has its own copy of > every domain it belongs to. So our little system would actually contain > eight sched_domain structures: one copy of the CPU-level domain and one copy > of the top-level domain for every processor. Things are implemented this way > for performance reasons: the scheduler must be very fast, which > contraindicates sharing this fundamental data structure between processors. > The structure is, in any case, almost entirely read-only after it has been > set up, so it can be replicated without trouble." > but as I know, some fields of struct sched_domain are not read-only, > they can be modified, such as > last_balance. If it need to maintain consistent state in each top-level > sched_domain , it's better to share the structure . So top-level > sched_domains's are inconsitent , my testing code confirmed this. > Inconsistent should be avoided , shouldn't it? Here is a reply from a co-worker (who is not on the list, but whom I've added as a CC). Hope it helps. -Nish On Mon, 15 Nov 2004 10:30:08 -0800, Darren Hart <dvhltc@xxxxxxxxxx> wrote: > There has been much debate as to the use of per-cpu sched-domains. As > you mentioned, things like last_balance are currently different for each > CPU of a domain. It actually indicates "when this CPU was last balanced > at this domain level". Personally I agree that the per-cpu > sched-domains are unneccesary and rewrote it to use a single shared > tree. My patch was rejected because of some harmless race conditions (a > counting variable may have updated twice by different CPUs to the same > value) and some concerns that structures such as these "should" be > per-cpu. My performance tests showed the unified domains to actually be > marginally faster (granted it was probably statistical noise). > > This is still rubbing some people (such as yourself) the wrong way and > work *is* well underway to provide a better solution. Stay tuned... > > --Darren Hart -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
