Path: utzoo!utgpu!watmath!att!cbnewsh!dwc From: dwc@cbnewsh.ATT.COM (Malaclypse the Elder) Newsgroups: comp.arch Subject: Re: TLB traffic reports (was Re: Cycle Counter) Message-ID: <3108@cbnewsh.ATT.COM> Date: 16 Aug 89 00:54:16 GMT References: <4221@orca.WV.TEK.COM> Distribution: comp Organization: The Legion of Dynamic Discord Lines: 28 In article <4221@orca.WV.TEK.COM>, andrew@frip.WV.TEK.COM (Andrew Klossner) writes: > [] > > "When a programmer suspects thrashing, the average OS can help > by reporting paging rates, task switch counts, interrupt load, > ethernet packets, and so on. The OS typically is unable to > report on cache traffic or on TLB traffic." > > An OS hacker could get most of the way there without hardware assist by > making regular (once per clock tick?) sweeps through the page tables, > noting and clearing the "page used" bits and flushing the TLB. For > example, it wouldn't take more than a couple of days to fit something > like this into Unix system V, including the statistic reporting utility. > i have done this myself and have to say that this technique does not generally get you enough information to find out about cache or TLB traffic. remember that looking through the page tables gives you a page sized resolution in memory address. this is typically not fine enough granularity to infer anything about a reference's effect on a cache. also, the TLB is a translation lookaside buffer that helps to reduce the number of memory references needed to decode a virtual address. looking at whether a page has been referenced in the past clock tic gives you no idea if it is still in the TLB. finally, a clock tic resolution is too coarse to do much but see rough memory behavior...useful but not what the original poster wanted. danny chen att!hocus!dwc