Searched hist:226840 (Results 1 - 2 of 2) sorted by relevance
| /freebsd-11-stable/sys/geom/eli/ | ||
| H A D | g_eli.h | diff 226840 Thu Oct 27 14:28:15 MDT 2011 pjd Before this change when GELI detected hardware crypto acceleration it will start only one worker thread. For software crypto it will start by default N worker threads where N is the number of available CPUs. This is not optimal if hardware crypto is AES-NI, which uses CPU for AES calculations. Change that to always start one worker thread for every available CPU. Number of worker threads per GELI provider can be easly reduced with kern.geom.eli.threads sysctl/tunable and even for software crypto it should be reduced when using more providers. While here, when number of threads exceeds number of CPUs avilable don't reduce this number, assume the user knows what he is doing. Reported by: Yuri Karaban <dev@dev97.com> MFC after: 3 days |
| H A D | g_eli.c | diff 226840 Thu Oct 27 14:28:15 MDT 2011 pjd Before this change when GELI detected hardware crypto acceleration it will start only one worker thread. For software crypto it will start by default N worker threads where N is the number of available CPUs. This is not optimal if hardware crypto is AES-NI, which uses CPU for AES calculations. Change that to always start one worker thread for every available CPU. Number of worker threads per GELI provider can be easly reduced with kern.geom.eli.threads sysctl/tunable and even for software crypto it should be reduced when using more providers. While here, when number of threads exceeds number of CPUs avilable don't reduce this number, assume the user knows what he is doing. Reported by: Yuri Karaban <dev@dev97.com> MFC after: 3 days |
Completed in 78 milliseconds