On Tue, Oct 09, 2012 at 04:43:11PM +0200, intrigeri wrote:
> anonym wrote (09 Oct 2012 14:17:45 GMT) :
> > * feature/hugetlb_mem_wipe:
>
> > - With PAE kernel:
> > * Patterns remaining after wipe: ~39K ≃ 600 KiB of memory
> > * Time required for wipe: 2.5 seconds.
>
> > - With "normal" non-PAE kernel:
> > * Patterns remaining after wipe: 51K ≃ 800 KiB of memory. Also, in
> > this case hugetlb_mem_wipe exits at 51% progress with the
> > following error:
> > [...]
> > * Time required for wipe: ~1 second.
>
> This looks very promising!
>
> Ague, what are the advantages of this solution, compared to the "fill
> a tmpfs" idea you also had?
>
> (The latter would arguably have a simpler implementation, that most of
> us could understand and debug, contrary to the fancy hugetlb_mem_wipe
> one. Simplicity matters.)
tmpfs currently does not use huge pages, so this is doomed to be slower.
Also I was a bit disappointed by how the kernel currently handles
out-of-memory with when using tmpfs: instead of erroring write(2) with
ENOSPC, it simply kills the process. This makes it harder to implement a
nice progress bar... But yeah, combination of dd, pv and a tmpfs should
also be able to do a faire amount of wiping.
hugetlb_mem_wipe is written in C, but it is fairly classic C/Unix code.
The most delicate part is the call to mmap(2), but it is a matter of
finding the right set of options. Huge pages are a fancy Linux feature,
true, but I was able to find examples easily.
To sum it up: hugetlb_mem_wipe is mostly done, is very likely to be
faster than other solutions and has a nice progress bar.
--
Ague
