Messages in this thread | | | Date | Mon, 22 Jun 2009 13:55:53 +0200 | From | Ingo Molnar <> | Subject | Re: I.10 - Event buffer minimal useful size |
| |
> 10/ Event buffer minimal useful size > > As it stands, the buffer header occupies the first page, even > though the buffer header struct is 32-byte long. That's a lot of > precious RLIMIT_MEMLOCK memory wasted. > > The actual buffer (data) starts at the next page (from builtin-top.c): > > static void mmap_read_counter(struct mmap_data *md) > { > unsigned int head = mmap_read_head(md); > unsigned int old = md->prev; > unsigned char *data = md->base + page_size; > > Given that the buffer "full" notification are sent on page > crossing boundaries, if the actual buffer payload size is 1 page, > you are guaranteed to have your samples overwritten. > > This leads me to believe that the minimal buffer size to get > useful data is 3 pages. This is per event group per thread. That > puts a lot of pressure on RLIMIT_MEMLOCK which is ususally set > fairly low by distros.
Regarding notifications: you can actually tell it to generate wakeups every 'n' events instead of at page boundaries. (See: attr.wakeup_events).
Regarding locked pags: there is an extra per user mlock limit for perf counters found in sysctl_perf_counter_mlock so it can be configured independently. Furthermore, the accounting is done on a per struct user basis, not on a per task basis - which makes the use of locked pages far less of an issue to distros.
Regarding using 4K for the sampling data header: we are making use of that property. We recently extended the header to include more fields and having it writable - so the 4K MMU separation between data header and data pages very much paid off already - and it could provide more advantages in the future.
| |