On Mon, Jun 12, 2023 at 06:05:02PM +0800, Leo Yan wrote: > On Mon, Jun 12, 2023 at 04:35:07PM +0800, Shuai Xue wrote: > > [...] > > > > Furthermore, I believe the AUX trace pages are only mapped for VMA > > > (continuous virtual address), the kernel will defer to map to physical > > > pages (which means it's not necessarily continuous physical pages) > > > when handling data abort caused by accessing the pages. > > > > I don't know why the rb->aux_pages is limit to allocated with continuous physical pages. > > so I just add a check to avoid oops and report a proper error code -EINVAL to > > user. > > > > I would like to use vmalloc() family to replace kmalloc() so that we could support > > allocate a more large AUX area if it is not necessarily continuous physical pages. > > Should we remove the restriction? > > As you said, we are now able to support a maximum AUX trace buffer > size of up to 2GiB, and AUX trace buffer is per CPU wise. Ouch, I reviewed my notes and correct myself: For per thread mode, perf tool only allocates one generic ring buffer and one AUX ring buffer for the whole session; for the system wide mode, perf allocates the generic ring buffer and the AUX ring buffer per CPU wise. > Seems to me, 2GiB AUX buffer per CPU is big enough for most tracing > scenarios, right? Except you can provide profiling scenario which > must use bigger buffer size. But I think this question is still valid. > Another factor is the allocation of buffers from kmalloc() offers better > performance compared to allocation from vmalloc(), this is also > important for perf core layer. > > Thanks, > Leo
