Date: Tue, 8 Dec 2009 21:25:55 +0100 From: Wiktor Niesiobedzki <bsd@w.evip.pl> To: Pawel Jakub Dawidek <pjd@freebsd.org> Cc: freebsd-geom <freebsd-geom@freebsd.org> Subject: Re: geli freezing 8.0 RELEASE and 7.2-STABLE Message-ID: <2ae8edf30912081225i224de5cg3a76beb3fda85ff7@mail.gmail.com> In-Reply-To: <20091207213408.GE1795@garage.freebsd.pl> References: <2ae8edf30912050724i6f196e53y40ccd06970d59a7a@mail.gmail.com> <20091207213408.GE1795@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
2009/12/7 Pawel Jakub Dawidek <pjd@freebsd.org>: > Hi Wiktor:) > > My guess is that this is because GELI worker threads are running with > too high priority (at least for your configuration). > > If I am right, the patch below should help you: > > =C2=A0 =C2=A0 =C2=A0 =C2=A0http://people.freebsd.org/~pjd/patches/g_eli.c= .2.patch Hi, Yes, it looks like it is thread priority problem. With this patch applied I do not see any freezes nor lags as before. I also did some small check, how this affects the performance, and I see no significant change. I saw some similiar reports here: http://forums.freebsd.org/showthread.php?t=3D6230 (though here it is connected with ZFS and compression). As far as I can imagine, what happens is, that ZFS usually sends data to disks as bulk transfers (every 5-10 seconds), so when I'm using GELI, it has quite a lot of data to encrypt, hence I observe some lagging. But then, I'm not sure, if compression on ZFS could expose this scenario in more aparent way. After having a quick look on http://www.freebsd.org/doc/en/books/arch-handbook/smp-design.html Does it mean, that alawys, when we have a a PRIBIO kthread running (geli thread encrypting data), lower priority processes (esp. userland processes) will not get any CPU? Sounds bit different than what I expected... Cheers, Wiktor Niesiobedzki
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2ae8edf30912081225i224de5cg3a76beb3fda85ff7>