----- On Apr 16, 2018, at 3:26 PM, Linus Torvalds torvalds@xxxxxxxxxxxxxxxxxxxx wrote: > On Mon, Apr 16, 2018 at 12:21 PM, Mathieu Desnoyers > <mathieu.desnoyers@xxxxxxxxxxxx> wrote: >> >> And I try very hard to avoid being told I'm the one breaking >> user-space. ;-) > > You *can't* be breaking user space. User space doesn't use this yet. > > That's actually why I'd like to start with the minimal set - to make > sure we don't introduce features that will come back to bite us later. > > The one compelling use case I saw was a memory allocator that used > this for getting per-CPU (vs per-thread) memory scaling. > > That code didn't need the cpu_opv system call at all. > > And if somebody does a ldload of a malloc library, and then wants to > analyze the behavior of a program, maybe they should ldload their own > malloc routines first? That's pretty much par for the course for those > kinds of projects. > > So I'd much rather we first merge the non-contentious parts that > actually have some numbers for "this improves performance and makes a > nice fancy malloc possible". > > As it is, the cpu_opv seems to be all about theory, not about actual need. I fully get your point about getting the minimal feature in. So let's focus on rseq only. I will rework the patchset so the rseq selftests don't depend on cpu_opv, and remove the cpu_opv stuff. I think it would be a good start for the Facebook guys (jemalloc), given that just rseq seems to be enough for them for now. It should be enough for the arm64 performance counters as well. Then we'll figure out what is needed to make other projects use it based on their needs (e.g. lttng-ust, liburcu, glibc malloc), and whether jemalloc end up requiring cpu_opv for memory migration between per-cpu pools after all. 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
