Re: kjournald wasting CPU in invert_lock fs/jbd/commit.c

[Andrew Morton]

Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
>
> I noticed that the code in commit.c of the jbd system can waste CPU
> cycles.

How did you notice?  By code inspection or by runtime observation?  If the
latter, please share.

> The offending code is as follows.
> 
> static int inverted_lock(journal_t *journal, struct buffer_head *bh)
> {
>         if (!jbd_trylock_bh_state(bh)) {
>                 spin_unlock(&journal->j_list_lock);
>                 schedule();
>                 return 0;
>         }
>         return 1;
> }

"offending" is a good description.  That code sucks.  But it sits on the
edge between two subsystems which really really want to take those locks in
opposite order.


> This code makes a loop if the jbd_trylock_bh_state fails. This code will
> wait till whoever owns the lock releases it. But it is really in a busy
> loop and will only be interrupted when the kjournald uses up all its
> quota.  So it's basically just wasting CPU cycles here.

Yeah.  But these _are_ spinlocks, so spinning is what's supposed to happen.
 Maybe we should dump that silly schedule() and just do cpu_relax(). 
Although I do recall once theorising that the time we spend in the
schedule() might be preventing livelocks.

>  The following
> patch should fix this.
> 
> Signed-off-by: Steven Rostedt rostedt@xxxxxxxxxxx

Please put "<>" around the email address.

> ---
> --- a/fs/jbd/commit.c	2005-07-11 17:51:37.000000000 -0400
> +++ b/fs/jbd/commit.c	2005-07-11 17:51:58.000000000 -0400
> @@ -87,7 +87,7 @@ static int inverted_lock(journal_t *jour
>  {
>  	if (!jbd_trylock_bh_state(bh)) {
>  		spin_unlock(&journal->j_list_lock);
> -		schedule();
> +		yield();
>  		return 0;
>  	}
>  	return 1;

Nope, yield() can cause terribly long delays when other tasks are cpu-bound.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/