On 2023/6/12 18:25, Leo Yan wrote: > 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. I see, I don't have such profiling scenario, let's leave the restriction untouched and I will move the sanity check into rb_alloc_aux(). >> >> Thanks, >> Leo Thank you. Best Regards, Shuai
