Messages in this thread | | | Date | Mon, 6 Jul 2009 00:27:20 +0900 | Subject | Re: [PATCH 5/5] add NR_ANON_PAGES to OOM log | From | Minchan Kim <> |
| |
On Mon, Jul 6, 2009 at 12:16 AM, Wu Fengguang<fengguang.wu@intel.com> wrote: > On Sun, Jul 05, 2009 at 11:04:17PM +0800, Minchan Kim wrote: >> On Sun, Jul 5, 2009 at 10:19 PM, KOSAKI >> Motohiro<kosaki.motohiro@jp.fujitsu.com> wrote: >> >>> > > + printk("%ld total anon pages\n", global_page_state(NR_ANON_PAGES)); >> >>> > > printk("%ld total pagecache pages\n", global_page_state(NR_FILE_PAGES)); >> >>> > >> >>> > Can we put related items together, ie. this looks more friendly: >> >>> > >> >>> > Anon:XXX active_anon:XXX inactive_anon:XXX >> >>> > File:XXX active_file:XXX inactive_file:XXX >> >>> >> >>> hmmm. Actually NR_ACTIVE_ANON + NR_INACTIVE_ANON != NR_ANON_PAGES. >> >>> tmpfs pages are accounted as FILE, but it is stay in anon lru. >> >> >> >> Right, that's exactly the reason I propose to put them together: to >> >> make the number of tmpfs pages obvious. >> >> >> >>> I think your proposed format easily makes confusion. this format cause to >> >>> imazine Anon = active_anon + inactive_anon. >> >> >> >> Yes it may confuse normal users :( >> >> >> >>> At least, we need to use another name, I think. >> >> >> >> Hmm I find it hard to work out a good name. >> >> >> >> But instead, it may be a good idea to explicitly compute the tmpfs >> >> pages, because the excessive use of tmpfs pages could be a common >> >> reason of OOM. >> > >> > Yeah, explicite tmpfs/shmem accounting is also useful for /proc/meminfo. >> >> Do we have to account it explicitly? > > When OOM happens, one frequent question to ask is: are there too many > tmpfs/shmem pages? Exporting this number makes our oom-message-decoding > life easier :)
Indeed.
>> If we know the exact isolate pages of each lru, >> >> tmpfs/shmem = (NR_ACTIVE_ANON + NR_INACTIVE_ANON + isolate(anon)) - >> NR_ANON_PAGES. >> >> Is there any cases above equation is wrong ? > > That's right, but the calculation may be too complex (and boring) for > our little brain ;)
Yes. if something is change in future or we miss someting, the above question may be wrong. I wanted to remove overhead of new accouting.
Anyway, I think it's not a big cost in normal system. So If you want to add new accounting, I don't have any objection. :)
> Thanks, > Fengguang >
-- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |