How to signal kernel that shared library is not in use by any process anymore ?
levonshe at yandex.com
Thu Dec 27 02:47:42 EST 2018
Thanks for you your reply.
It help me to better express my question
>From the application I can access /proc/self/maps and see which memory is mapped for my library I do not intend to use after application passes init phase.
I would like to unmap this memory region, but since I do not have file descriptor for this so I can not do this.
Only kernel can unmap this memory for me,
I am willing to pass library name or address to system cal, but IMHO such system call does not exist.
Should I rely on memory manager which will use reuse this pages because they will never page faulted back ?
I am afraid that since this is C++ lib, some pages are modified and will not be considered clean ?
Thanks again for your precious time.
Perhaps somebody from the list can respond too.
Thank you all
21.12.2018, 18:31, "Greg KH" <greg at kroah.com>:
> On Fri, Dec 21, 2018 at 05:20:36PM +0300, Lev Olshvang wrote:
>> Hi All,
>> I have an executable (C++) which is the exclusive user of the some shared library that it uses only during the initialization phase.
>> I would like to free memory used by this shared library, because I am running on embedded system.
>> How can I achieve this?
>> I know that dlopen() will load shared library, and hope that following dlclose() will free this lib memory.
> That right there is how you "achieve" this, call dlclose() and all will
> be fine. If your system needs the memory that was being used, it will
> reclaim it from the memory that was previously being used by the library
> at this point in time.
> Nothing else needs to be done.
> Have you tested this and found it not to work properly?
>> 1. Still I do not know what method should be used to make dynamic linker look again into executable and resolve symbols of the newly appeared symbols ?
> What "newly appeared symbols"?
> If you need to load the library again, call dlopen().
>> 2. And how to tell the dynamic linker ld-linux.so to postpone the symbol resolution until dlopen() will load the library?
> It will not happen until you tell it to, right?
>> 3. Whether to compile and link executable with this library or leave unresolved symbols?
> It sounds like you don't really know what type of problem you are trying
> to solve here.
> Back up, what is the real issue you are having with the kernel at this
> point in time?
> greg k-h
More information about the Kernelnewbies