By: Emil Briggs (me.delete@this.nowherespam.com),
Room: Moderated Discussions
Jörn Engel (joern.delete@this.purestorage.com) on January 4, 2020 11:34 am wrote:
> Linus Torvalds (torvalds.delete@this.linux-foundation.org) on January 3, 2020 6:05 pm wrote:
> >
> > (Pretty much every time we picked an unfair - but fast - locking model in the
> > kernel, we ended up regretting it eventually, and had to add fairness).
>
> What are your thoughts about limiting unfairness. Totally fair is bad for throughput,
> totally unfair is horrible for latency, sure. But can there be a middle-ground where
> local CPUs can sneak in and take the lock for a short while? Something like:
>
> if (no waiters) lock();
> if (waiters && time() if (first waiter) timestamp = time() + unfair_period;
> wait();
>
> I know there are lots of details to get right before this has any chance of working. But
> are there any fundamental problem that disqualify this approach independently of details?
It seems to me that getting this to work well in the general case would be really hard. There are times when it's OK to be totally unfair. An HPC compute node for example where you have a guarantee that no other user space procs will be running. But for any general purpose system how would you tune it?
> Linus Torvalds (torvalds.delete@this.linux-foundation.org) on January 3, 2020 6:05 pm wrote:
> >
> > (Pretty much every time we picked an unfair - but fast - locking model in the
> > kernel, we ended up regretting it eventually, and had to add fairness).
>
> What are your thoughts about limiting unfairness. Totally fair is bad for throughput,
> totally unfair is horrible for latency, sure. But can there be a middle-ground where
> local CPUs can sneak in and take the lock for a short while? Something like:
>
> if (no waiters) lock();
> if (waiters && time() if (first waiter) timestamp = time() + unfair_period;
> wait();
>
> I know there are lots of details to get right before this has any chance of working. But
> are there any fundamental problem that disqualify this approach independently of details?
It seems to me that getting this to work well in the general case would be really hard. There are times when it's OK to be totally unfair. An HPC compute node for example where you have a guarantee that no other user space procs will be running. But for any general purpose system how would you tune it?
