2005-12-01 20:22:27

by Dinakar Guniguntala

Subject: Perf degradation from -rt14 onwards

I was wondering why the following change was made from -rt14
onwards.


@@ -1634,7 +1531,7 @@ asmlinkage long sys_futex(u32 __user *ua
int val3)
{
struct timespec t;
- unsigned long timeout = MAX_SCHEDULE_TIMEOUT;
+ unsigned long timeout = 0;

This was introduced in patch-2.6.14-rt13-rf3 by David.

This seems to return spurious -ETIMEDOUT errors even in the
non-robust code and results in userspace (glibc) retrying
several mutex operations before it succeeds. I was chasing
down a degradation of performance of some testcases and was
able to fix those by reverting this change back.

-Dinakar

2005-12-01 20:58:40

by David Singleton

Subject: Re: Perf degradation from -rt14 onwards

Dinakar Guniguntala wrote:

>I was wondering why the following change was made from -rt14
>onwards.
>
>
>@@ -1634,7 +1531,7 @@ asmlinkage long sys_futex(u32 __user *ua
> int val3)
> {
> struct timespec t;
>- unsigned long timeout = MAX_SCHEDULE_TIMEOUT;
>+ unsigned long timeout = 0;
>
>This was introduced in patch-2.6.14-rt13-rf3 by David.
>
>This seems to return spurious -ETIMEDOUT errors even in the
>non-robust code and results in userspace (glibc) retrying
>several mutex operations before it succeeds. I was chasing
>down a degradation of performance of some testcases and was
>able to fix those by reverting this change back.
>
>

Yes. The default timeout should be set to MAX_SCHEDULE_TIMEOUT, not zero.

David

> -Dinakar
>
>
>

2005-12-01 21:20:45

by Ingo Molnar

Subject: Re: Perf degradation from -rt14 onwards

* Dinakar Guniguntala <[email protected]> wrote:

> I was wondering why the following change was made from -rt14
> onwards.
>
>
> @@ -1634,7 +1531,7 @@ asmlinkage long sys_futex(u32 __user *ua
> int val3)
> {
> struct timespec t;
> - unsigned long timeout = MAX_SCHEDULE_TIMEOUT;
> + unsigned long timeout = 0;
>
> This was introduced in patch-2.6.14-rt13-rf3 by David.
>
> This seems to return spurious -ETIMEDOUT errors even in the non-robust
> code and results in userspace (glibc) retrying several mutex
> operations before it succeeds. I was chasing down a degradation of
> performance of some testcases and was able to fix those by reverting
> this change back.

nice catch! I've undone this change in my tree.

Ingo