Re: pdflush and dm-crypt

[Andrew Morton]

Christophe Saout <christophe@xxxxxxxx> wrote:
>
> Am Mo, den 29.03.2004, um 16:12 Uhr -0800, schrieb Andrew Morton:
> 
>  > How come?  Isn't this problem just "gee, we have a lot of stuff to encrypt
>  > during writeback"?  If so, then it should be sufficient to poke a hole in
>  > the encryption loop?
>  > 
>  > --- 25/drivers/md/dm-crypt.c~a	Mon Mar 29 16:11:49 2004
>  > +++ 25-akpm/drivers/md/dm-crypt.c	Mon Mar 29 16:11:56 2004
>  > @@ -669,6 +669,7 @@ static int crypt_map(struct dm_target *t
>  >  		/* out of memory -> run queues */
>  >  		if (remaining)
>  >  			blk_congestion_wait(bio_data_dir(clone), HZ/100);
>  > +		cond_resched();
>  >  	}
>  >  
>  >  	/* drop reference, clones could have returned before we reach this */
> 
>  cryptoapi always does this after every block. It also happens with
>  preemption enabled. I got feedback from a person who said that renicing
>  pdflush to 0 helped. So it looks like the CPU scheduler doesn't want to
>  schedule pdflush away. Hmm.

Oh, OK, since pdflush was converted to use the kthread stuff it has been
running at keventd's `nice -10'.  You can probably renice it by hand.



diff -puN mm/pdflush.c~pdflush-nice-0 mm/pdflush.c
--- 25/mm/pdflush.c~pdflush-nice-0	2004-03-30 01:59:17.795116816 -0800
+++ 25-akpm/mm/pdflush.c	2004-03-30 02:02:29.865917616 -0800
@@ -177,6 +177,12 @@ static int __pdflush(struct pdflush_work
 static int pdflush(void *dummy)
 {
 	struct pdflush_work my_work;
+
+	/*
+	 * pdflush can spend a lot of time doing encryption via dm-crypt.  We
+	 * don't want to do that at keventd's priority.
+	 */
+	set_user_nice(current, 0);
 	return __pdflush(&my_work);
 }
 

_

-
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/