Am 07.11.2010 10:57, Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> Am 07.11.2010 09:31, Gilles Chanteperdrix wrote: >>> Jan Kiszka wrote: >>>>>> Anyway, after some thoughts, I think we are going to try and make the >>>>>> current situation work instead of going back to the old way. >>>>>> >>>>>> You can find the patch which attempts to do so here: >>>>>> http://sisyphus.hd.free.fr/~gilles/sched_status.txt >>>>> Ack. At last, this addresses the real issues without asking for >>>>> regression funkiness: fix the lack of barrier before testing XNSCHED in >>>> Check the kernel, we actually need it on both sides. Wherever the final >>>> barriers will be, we should leave a comment behind why they are there. >>>> Could be picked up from kernel/smp.c. >>> We have it on both sides: the non-local flags are modified while holding >>> the nklock. Unlocking the nklock implies a barrier. >> >> I think this does not work if nklock is used nested, ie. hold across >> xnsched_set_resched and the next xnpod_schedule. > > Ok. There is a race here, even without nesting, we need a barrier before > sending the IPI. > >>>> I do not understand the split logic - or some bits are simply not yet >>>> migrated. XNHDEFER, XNSWLOCK, XNKCOUT are all local-only as well, no? >>>> Then better put them in the _local_ status field, that's more consistent >>>> (and would help if we once wanted to optimize their cache line usage). >>> Maybe the naming is not good the. ->status is everything which is >>> modified under nklock, ->lstatus is for XNINIRQ and XNHTICK which are >>> modified without holding the nklock. >> >> And this is not a good clustering IMHO as it makes no difference for a >> local-only flag if it is protected by nklock or not (as long as IRQs are >> off, of course). What makes a difference it the CPU using the related >> field. If we group according to local and remote usage, less cache line >> bouncing can be achieved (of both fields are also cache line aligned, >> but that is a second step that only helps if the first is made). > > The two status are in the same cache line. >
Which can (and likely should) be changed - if the fields are logically separated first. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list [email protected] https://mail.gna.org/listinfo/xenomai-core
