----- On Jan 11, 2016, at 6:03 PM, Josh Triplett josh@xxxxxxxxxxxxxxxx wrote: > On Mon, Jan 11, 2016 at 10:38:28PM +0000, Seymour, Shane M wrote: >> I have some concerns and suggestions for you about this. >> >> What's to stop someone in user space from requesting an arbitrarily large number >> of CPU # cache locations that the kernel needs to allocate memory to track and >> each time the task migrates to a new CPU it needs to update them all? Could you >> use it to dramatically slow down a system/task switching? Should there be a >> ulimit type value or a sysctl setting to limit the number that you're allowed >> to register per-task? > > The documented behavior of the syscall allows only one location per > thread, so the kernel can track that one and only address rather easily > in the task_struct. Allowing dynamic allocation definitely doesn't seem > like a good idea. The current implementation now allows more than one location per thread. Which piece of documentation states that only one location per thread is allowed ? This was indeed the case for the prior implementations, but I moved to implementing a linked-list of cpu_cache areas per thread to allow the getcpu_cache system call to be used by more than a single shared object within a given program. Without the linked list, as soon as more than one shared object try to register their cache, the first one will prohibit all others from doing so. We could perhaps try to document that this system call should only ever be used by *libc, and all libraries and applications should then use the libc TLS cache variable, but it seems rather fragile, and any app/lib could try to register its own cache. Thoughts ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
