Messages in this thread | | | From | Thomas Gleixner <> | Subject | Re: [patch 02/20] posix-timers: Ensure timer ID search-loop limit is valid | Date | Tue, 09 May 2023 11:30:01 +0200 |
| |
On Mon, May 08 2023 at 23:57, Thomas Gleixner wrote: > On Sat, May 06 2023 at 01:36, Thomas Gleixner wrote: >> The only alternative solution I could come up with is a paritioned >> xarray where the index space would be segmented for each TGID, i.e. >> >> segment.start = TGID * MAX_TIMERS_PER_PROCESS >> segment.end = segment.start + MAX_TIMERS_PER_PROCESS - 1 >> >> where MAX_TIMERS_PER_PROCESS could be a copius 2^16 which would work for >> both 32bit and 64bit TID limits. >> >> That would avoid the hash table lookups and the related issues, but OTH >> it would require to allocate one extra page per TGID if the application >> uses a single posix timer. >> >> Not sure whether that's worth it though. > > More thoughts on this. If we go there and accept the extra page of > memory then we can just go all the way and make the xarray per process, > actually per signal.
Thinking more about it. The current scheme how timer ID allocation works is really interesting vs. CRIU.
Assume a process creates/deletes timers frequently. It's not hard to move the next ID close to INT_MAX, i.e. 2G
Now checkpoint that thing and restore it which means to do the create/delete dance to move next ID up to the last one-1. Will only take a couple of hours....
Thanks,
tglx
| |