From: Linhaifeng <haifeng.lin-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
To: "Qiu,
Michael" <michael.qiu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"dev-VfR2kkLFssw@public.gmane.org"
<dev-VfR2kkLFssw@public.gmane.org>
Subject: Re: [PATCH v2] support free hugepages
Date: Wed, 29 Oct 2014 14:40:19 +0800 [thread overview]
Message-ID: <54508BD3.1080001@huawei.com> (raw)
In-Reply-To: <533710CFB86FA344BFBF2D6802E60286C7CBAE-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
On 2014/10/29 14:14, Qiu, Michael wrote:
> 在 10/29/2014 1:49 PM, linhaifeng 写道:
>> rte_eal_hugepage_free() is used for unlink all hugepages.If you want to
>> free all hugepages you must make sure that you have stop to use it,and you
>> must call this function before exit process.
>>
>> Signed-off-by: linhaifeng <haifeng.lin-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
>> ---
>> .../lib/librte_eal/common/include/rte_memory.h | 11 ++++++++
>> .../lib/librte_eal/linuxapp/eal/eal_memory.c | 31 ++++++++++++++++++++++
>> 2 files changed, 42 insertions(+)
>>
>> diff --git a/dpdk/dpdk-1.7.0/lib/librte_eal/common/include/rte_memory.h b/dpdk/dpdk-1.7.0/lib/librte_eal/common/include/rte_memory.h
>> index 4cf8ea9..f6ad95f 100644
>> --- a/dpdk/dpdk-1.7.0/lib/librte_eal/common/include/rte_memory.h
>> +++ b/dpdk/dpdk-1.7.0/lib/librte_eal/common/include/rte_memory.h
>> @@ -172,6 +172,17 @@ unsigned rte_memory_get_nchannel(void);
>> */
>> unsigned rte_memory_get_nrank(void);
>>
>> +/**
>> + * Unlink all hugepages which created by dpdk.
>> + *
>> + * @param void
>> + *
>> + * @return
>> + * 0: successfully
>> + * negative: error
>> + */
>> +int rte_eal_hugepage_free(void);
>> +
>> #ifdef RTE_LIBRTE_XEN_DOM0
>> /**
>> * Return the physical address of elt, which is an element of the pool mp.
>> diff --git a/dpdk/dpdk-1.7.0/lib/librte_eal/linuxapp/eal/eal_memory.c b/dpdk/dpdk-1.7.0/lib/librte_eal/linuxapp/eal/eal_memory.c
>> index f2454f4..109207c 100644
>> --- a/dpdk/dpdk-1.7.0/lib/librte_eal/linuxapp/eal/eal_memory.c
>> +++ b/dpdk/dpdk-1.7.0/lib/librte_eal/linuxapp/eal/eal_memory.c
>> @@ -98,6 +98,13 @@
>> #include "eal_filesystem.h"
>> #include "eal_hugepages.h"
>>
>> +struct hugepage_table {
>> + struct hugepage_file *hugepg_tbl;
>> + unsigned nr_hugefiles;
>> +};
>> +
>> +static struct hugepage_table g_hugepage_table;
>> +
>> /**
>> * @file
>> * Huge page mapping under linux
>> @@ -1202,6 +1209,7 @@ rte_eal_hugepage_init(void)
>> (unsigned)
>> (used_hp[i].hugepage_sz / 0x100000),
>> j);
>> + g_hugepage_table.nr_hugefiles += used_hp[i].num_pages[j];
>> }
>> }
>> }
>> @@ -1237,6 +1245,8 @@ rte_eal_hugepage_init(void)
>> goto fail;
>> }
>>
>> + g_hugepage_table.hugepg_tbl = hugepage;
>> +
>> /* free the temporary hugepage table */
>> free(tmp_hp);
>> tmp_hp = NULL;
>> @@ -1487,6 +1497,27 @@ error:
>> return -1;
>> }
>>
>> +int
>> +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;
>> + int ret = 0;
>> +
>> + for (i = 0; i < nr_hugefiles; i++) {
>> + ret = unlink(hugepg_tbl[i].filepath);
>> + if (ret != 0) {
>> + RTE_LOG(ERR, EAL, "Failed to unlink %s", hugepg_tbl[i].filepath);
>> + return ret;
>> + }
>> + hugepg_tbl[i].orig_va = NULL;
>
> BTW, is it better to first set hugepg_tbl[i].orig_vato NULL, then unlink
> filepath?
> It may be not a good idea to first remove then set to NULL.
>
> Thanks,
> Michael
>
If first set hugepg_tbl[i].orig_va to NULL,then failed to unlink you have to restore hugepg_tbl[i].orig_va.
So I first to unlink for less codes.
>> + }
>> +
>> + RTE_LOG(INFO, EAL, "unlink %u hugepage files\n", nr_hugefiles);
>> + return ret;
>> +}
>> +
>> static int
>> rte_eal_memdevice_init(void)
>> {
>
>
> .
>
--
Regards,
Haifeng
next prev parent reply other threads:[~2014-10-29 6:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-29 5:47 [PATCH v2] support free hugepages linhaifeng
2014-10-29 6:14 ` Qiu, Michael
[not found] ` <533710CFB86FA344BFBF2D6802E60286C7CBAE-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2014-10-29 6:40 ` Linhaifeng [this message]
2014-10-29 8:04 ` Qiu, Michael
[not found] ` <533710CFB86FA344BFBF2D6802E60286C7CC55-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2014-10-29 8:15 ` Linhaifeng
[not found] ` <1414561659-7408-1-git-send-email-haifeng.lin-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2014-10-30 3:17 ` Matthew Hall
2014-10-30 15:32 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54508BD3.1080001@huawei.com \
--to=haifeng.lin-hv44wf8li93qt0dzr+alfa@public.gmane.org \
--cc=dev-VfR2kkLFssw@public.gmane.org \
--cc=michael.qiu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.