On Thu, Dec 01, 2016 at 08:38:15AM +0100, Vlastimil Babka wrote: > >> By default config this should not be used on x86. > > What do you mean by that statement? > > I mean that the 16 mbytes for generic CMA area is not a default on x86: > > config CMA_SIZE_MBYTES > int "Size in Mega Bytes" > depends on !CMA_SIZE_SEL_PERCENTAGE > default 0 if X86 > default 16 d7be003a9d275299f5ee36bbdf156654f59e08e9 (v3.18-2122-gd7be003a9d27) is there the 0MB if-x86 default was added to the tree. Prior to that, it was 16MiB, and that's where my system picked up the value from.
I have a record of all my kconfigs, because I use oldconfig each time (going back 8 years to 2.6.27) # Added in 3.12.0-00001-g5f258d0 CONFIG_CMA=y # Added in 3.16.0-rc6-00042-g67dd8f3 CONFIG_CMA_ALIGNMENT=8 CONFIG_CMA_AREAS=7 CONFIG_CMA_SIZE_MBYTES=16 CONFIG_CMA_SIZE_SEL_MBYTES=y CONFIG_DMA_CMA=y So the next question, is why did I pick up CMA in 3.16.0-rc6-00042-g67dd8f3... I'll poke at that. > > Yes, I'd say if there's a fallback without much penalty, nowarn makes > > sense. If the fallback just tries multiple addresses until success, then > > the warning should only be issued when too many attempts have been made. > On the other hand, if the warnings are correlated with high kernel CPU usage, > it's arguably better to be warned. Keep the rate-limit on the warning for cases like this? > >> > The rate of the problem starts slow, and also is relatively low on an > >> > idle > >> > system (my screens blank at night, no xscreensaver running), but it > >> > still ramps > >> > up over time (to the point of generating 2.5GB/hour of "(timestamp) > >> > alloc_contig_range: [83e4d9, 83e4da) PFNs busy"), with various addresses > >> > (~100 > >> > unique ranges for a day). > >> > > >> > My X workload is ~50 chrome tabs and ~20 terminals (over 3x 24" monitors > >> > w/ 9 > >> > virtual desktops per monitor). > >> So IIUC, except the messages, everything actually works fine? > > There's high kernel CPU usage that seems to roughly correlate with the > > messages, but I can't yet tell if that's due to the syslog itself, or > > repeated alloc_contig_range requests. > You could try running perf top. Will do in the morning. -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Trustee & Treasurer E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136