On Fri, Aug 11, 2017 at 10:06:37PM +0900, Byungchul Park wrote: > On Fri, Aug 11, 2017 at 6:44 PM, Byungchul Park <[email protected]> > wrote: > > On Fri, Aug 11, 2017 at 05:52:02PM +0900, Byungchul Park wrote: > >> On Fri, Aug 11, 2017 at 04:03:29PM +0800, Boqun Feng wrote: > >> > Thanks for taking a look at it ;-) > >> > >> I rather appriciate it. > >> > >> > > > @@ -5005,7 +5003,7 @@ static int commit_xhlock(struct cross_lock > >> > > > *xlock, struct hist_lock *xhlock) > >> > > > static void commit_xhlocks(struct cross_lock *xlock) > >> > > > { > >> > > > unsigned int cur = current->xhlock_idx; > >> > > > - unsigned int prev_hist_id = xhlock(cur).hist_id; > >> > > > + unsigned int prev_hist_id = cur + 1; > >> > > > >> > > I should have named it another. Could you suggest a better one? > >> > > > >> > > >> > I think "prev" is fine, because I thought the "previous" means the > >> > xhlock item we visit _previously_. > >> > > >> > > > unsigned int i; > >> > > > > >> > > > if (!graph_lock()) > >> > > > @@ -5030,7 +5028,7 @@ static void commit_xhlocks(struct cross_lock > >> > > > *xlock) > >> > > > * hist_id than the following one, which is > >> > > > impossible > >> > > > * otherwise. > >> > > > >> > > Or we need to modify the comment so that the word 'prev' does not make > >> > > readers confused. It was my mistake. > >> > > > >> > > >> > I think the comment needs some help, but before you do it, could you > >> > have another look at what Peter proposed previously? Note you have a > >> > same_context_xhlock() check in the commit_xhlocks(), so the your > >> > previous overwrite case actually could be detected, I think. > >> > >> What is the previous overwrite case? > >> > >> ppppppppppwwwwwwwwwwwwiiiiiiiii > >> iiiiiiiiiiiiiii................ > >> > >> Do you mean this one? I missed the check of same_context_xhlock(). Yes, > >> peterz's suggestion also seems to work. > >> > >> > However, one thing may not be detected is this case: > >> > > >> > ppppppppppppppppppppppppppppppppppwwwwwwww > >> > wrapped > wwwwwww > >> > >> To be honest, I think your suggestion is more natual, with which this > >> case would be also covered. > >> > >> > > >> > where p: process and w: worker. > >> > > >> > , because p and w are in the same task_irq_context(). I discussed this > >> > with Peter yesterday, and he has a good idea: unconditionally do a reset > >> > on the ring buffer whenever we do a crossrelease_hist_end(XHLOCK_PROC). > > > > Ah, ok. You meant 'whenever _process_ context exit'. > > > > I need more time to be sure, but anyway for now it seems to work with > > giving up some chances for remaining xhlocks. > > > > But, I am not sure if it's still true even in future and the code can be > > maintained easily. I think your approach is natural and neat enough for > > that purpose. What problem exists with yours? >
My approach works but it has bigger memmory footprint than Peter's, so I
asked about whether you could consider Peter's approach.
> Let me list up the possible approaches:
>
> 0. Byungchul's approach
Your approach requires(additionally):
MAX_XHLOCKS_NR * sizeof(unsigned int) // because of the hist_id field
in hist_lock
+
(XHLOCK_CXT_NR + 1) * sizeof(unsigned int) // because of fields in
task_struct
bytes per task.
> 1. Boqun's approach
My approach requires(additionally):
MAX_XHLOCKS_NR * sizeof(unsigned int) // because of the hist_id field
in hist_lock
bytes per task.
> 2. Peterz's approach
And Peter's approach requires(additionally):
1 * sizeof(unsigned int)
bytes per task.
So basically we need some tradeoff between memory footprints and history
precision here.
> 3. Reset on process exit
>
> I like Boqun's approach most but, _whatever_. It's ok if it solves the
> problem.
> The last one is not bad when it is used for syscall exit, but we have to give
> up valid dependencies unnecessarily in other cases. And I think Peterz's
> approach should be modified a bit to make it work neatly, like:
>
> crossrelease_hist_end(...)
> {
> ...
> invalidate_xhlock(&xhlock(cur->xhlock_idx_max));
>
> for (c = 0; c < XHLOCK_CXT_NR; c++)
> if ((cur->xhlock_idx_max - cur->xhlock_idx_hist[c]) >=
> MAX_XHLOCKS_NR)
> invalidate_xhlock(&xhlock(cur->xhlock_idx_hist[c]));
> ...
> }
>
Haven't looked into this deeply, but my gut feeling is this is
unnecessary, will have a deep look.
Regards,
Boqun
> And then Peterz's approach can also work, I think.
>
> ---
> Thanks,
> Byungchul
signature.asc
Description: PGP signature
