Re: [dpdk-dev] [PATCH] add free hugepage function

[Bruce Richardson <bruce.richardson@intel.com>]

On Wed, Oct 29, 2014 at 02:49:05PM +0800, Linhaifeng wrote:
> 
> 
> On 2014/10/29 13:26, Qiu, Michael wrote:
> > 在 10/29/2014 11:46 AM, Matthew Hall 写道:
> >> On Wed, Oct 29, 2014 at 03:27:58AM +0000, Qiu, Michael wrote:
> >>> I just saw one return path with value '0', and no any other place 
> >>> return a negative value,  so it is better to  be designed as one
> >>> non-return function,
> >>>
> >>> +void
> >>> +rte_eal_hugepage_free(void)
> >>> +{
> >>> +	struct hugepage_file *hugepg_tbl = g_hugepage_table.hugepg_tbl;
> >>> +	unsigned i;
> >>> +	unsigned nr_hugefiles = g_hugepage_table.nr_hugefiles;
> >>> +
> >>> +	RTE_LOG(INFO, EAL, "unlink %u hugepage files\n", nr_hugefiles);
> >>> +
> >>> +	for (i = 0; i < nr_hugefiles; i++) {
> >>> +		unlink(hugepg_tbl[i].filepath);
> >>> +		hugepg_tbl[i].orig_va = NULL;
> >>> +	}
> >>> +}
> >>> +
> >>>
> >>> Thanks,
> >>> Michael
> >> Actually, I don't think that's quite right.
> >>
> >> http://linux.die.net/man/2/unlink
> >>
> >> "On success, zero is returned. On error, -1 is returned, and errno is set 
> >> appropriately." So it should be returning an error, and logging a message for 
> >> a file it cannot unlink or people will be surprised with weird failures.
> > 
> > Really need one message for unlink failed, but I'm afraid that if it
> > make sense for return an error code when application exit.
> > 
> > Thanks
> > Michael
> >> It also had some minor typos / English in the comments but we can fix that too.
> >>
> >> Matthew.
> >>
> > 
> > 
> > 
> Agree.May be it is not need to return error?
> -- 
> Regards,
> Haifeng
> 

May I throw out a few extra ideas.

The basic problem with DPDK and hugepages on exit, as you have already 
diagnosed, is not that the hugepages aren't released for re-use, its that 
the files inside the hugepage directory aren't unlinked. There are two 
considerations here that prevented us from coming up previously with a 
solution to this that we were fully happy with.
1. There is no automatic way (at least none that I'm aware of), to have the 
kernel automatically delete a file on exit. This means that any scheme to 
delete the files on application termination will have to be a voluntary one 
that won't happen if an app crashed or is forcibly terminated. That is why 
the EAL right now does the clean-up on the restart of the app instead.
2. The other consideration is multi-process. In a multi-process environment, 
it is unclear when exactly an app is finished - just because one process 
terminates does not mean that the whole app is finished with the hugepage 
files. If the files are deleted before a DPDK secondary process starts up, 
it won't be able to start as it won't be able to mmap the hugepage memory it 
needs.

Now, that being said, I think we could see about having automatic hugepage 
deletion controlled by an EAL parameter. That way, the parameter could be 
omitted in the multi-process case, but could be used for those who want to 
have a clean hugepage dir after app termination.

What I think we could do is, instead of having the app save the list of 
hugepages it uses as the app initializes, is to have the app delete the 
hugepage files as soon as it closes the filehandle for them. If my 
understanding is correct, the kernel will actually keep the hugepage memory 
around in the app as usual from that point onwards, and will only release it 
back [automatically] on app termination. New processes won't be able to mmap 
the file, but the running process will be unaffected. The best thing about 
this approach is that the hugepage file entries will be deleted whether or 
not the application terminates normally or crashes.

So, any thoughts? Would such a scheme work? I haven't prototyped it, yet, 
but I think it should work.

Regards,
/Bruce

PS: As well as multi-process not being able to use this scheme, I'd also 
note that this would prevent the dump_cfg utility app - or any other DPDK 
analysis app like it - from being used to inspect the memory area of the 
running process. That is another reason why I think the flag should not be 
set by default.