Is there any chance to increase the number of name spaces created by calling dlmopen()? I am working on new parallel execution model (named Process-in-Process (PiP), detailes: https://dl.acm.org/citation.cfm?id=3208045) and I want to create name spaces much more than 16 which is the current upper limit. I already have a patch to do this. It is very simple. Just increase the number of DL_NNS found in sysdeps/generic/ldsodefs.h. I would like to have around 300 which is mlarger than the number of cores available on Xeon Phi (KNL).
I'm not sure that it's a good idea to retrofit such execution models onto an existing dynamic loader. libc.so needs around 144 bytes of TLS space. Supporting 300 name spaces would need a static TLS reserve of at least 43 KiB, and this reserve could not be used for anything else. For such large numbers of name spaces, we would have to find a way to deal with initial-exec TLS memory used by the implementation itself.
It's been a long time since I posted and I almost forget about this issue. At last I got a comment, this is great! I understand your concern. Although I have only little knowledge about glibc including ld.so, I wonder if it is possible to dynamically allocate the 'TLS' regions. I also found that the recent audit implementation using a uint32_t as the audit flags for name spaces is not a good idea. Anyhow, I am very happy to have this feedback. P.S. If some of you might be interested in the PiP model, you can try it by downloading from; https://github.com/RIKEN-SysSoft/PiP I also uploaded some presentation slides which are much easier to read than reading the HPDC paper.
(In reply to Atsushi Hori from comment #2) > It's been a long time since I posted and I almost forget about this issue. > At last I got a comment, this is great! > > I understand your concern. Although I have only little knowledge about > glibc including ld.so, I wonder if it is possible to dynamically allocate > the 'TLS' regions. No, because the implementation is free to store pointers to TLS variables, so the allocation cannot be moved (and we might have to move it if its size changes).
Thank you, Florian, I think I know what TLS is, but what I wanted yo to do is expanding the size of name space table, or dynamically allocating name space entriesI believe this is independent from TLS variables. Just correct me, if I am wrong.
These two are related. Each namespace must load libc.so, and libc.so contains some TLS variables. The number of usable namespaces is therefore limited by the size of the static TLS reserve divided by the amount of initial-exec TLS memory that libc.so uses.
I discussed with the PiP (Process-in-Process) users on this issue. One idea, I hope you can accept this, was brought up. Could you make the DL_NNS (defined in sysdeps/generic/ldsodefs.h) a configure option?