Messages in this thread | | | Date | Fri, 20 Aug 2004 15:25:51 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH] shows Active/Inactive on per-node meminfo |
| |
Jesse Barnes <jbarnes@engr.sgi.com> wrote: > > On Friday, August 20, 2004 2:48 pm, Jesse Barnes wrote: > > On Friday, August 20, 2004 2:02 pm, mita akinobu wrote: > > > + for (i = 0; i < MAX_NR_ZONES; i++) { > > > + *active += zones[i].nr_active; > > > + *inactive += zones[i].nr_inactive; > > > + *free += zones[i].free_pages; > > > + } > > > +} > > > + > > > - *free += zone->free_pages; > > > + for_each_pgdat(pgdat) { > > > + unsigned long l, m, n; > > > + __get_zone_counts(&l, &m, &n, pgdat); > > > + *active += l; > > > + *inactive += m; > > > + *free += n; > > > } > > > > Just FYI, loops like this are going to be very slow on a large machine. > > Iterating over every node in the system involves a TLB miss on every > > iteration along with an offnode reference and possibly cacheline demotion. > > ...but I see that you're just adding the info to the per-node meminfo files, > so it should be ok as long as people access a node's meminfo file from a > local cpu. /proc/meminfo will still hurt a lot though. > > I bring this up because I ran into it once. I created a file > called /proc/discontig which printed out detailed per-node memory stats, one > node per line. On a large system it would literally take several seconds to > cat the file due to the overhead of looking at all the pages and zone > structures. >
So was that an ack, a nack or a quack?
I'll queue the patch up so it doesn't get lost - could you please take a closer look at the performance implications sometime, let me know?
- 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/
| |