| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <B80C0D24-033B-4B17-98C5-1645E3651FCD@dilger.ca> Date: Wed, 23 Feb 2011 17:41:31 -0700 From: Andreas Dilger <adilger@...ger.ca> To: Ted Ts'o <tytso@....edu> Cc: Rogier Wolff <R.E.Wolff@...wizard.nl>, linux-ext4@...r.kernel.org Subject: Re: fsck performance. On 2011-02-23, at 4:17 PM, Ted Ts'o wrote: > On Wed, Feb 23, 2011 at 03:24:18PM -0700, Andreas Dilger wrote: >> >> If you have the opportunity, I wonder whether the entire need for >> tdb can be avoided in your case by using swap and the icount >> optimization patches previously posted? > > Unfortunately, there are people who are still using 32-bit CPU's, so > no, swap is not a solution here. I agree it isn't a solution in all cases, but avoiding GB-sized realloc() in the code was certainly enough to fix problems for the original people who hit them. It likely also avoids a lot of memcpy() (depending on how realloc is implemented). Cheers, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists