G'Day Max, On Wed, 11 Jan 2006 [EMAIL PROTECTED] wrote:
> Hi Greg, > > Upon further reflection (and running your script), I am > very puzzled you are getting anywhere near 1000 segvn_fault > calls for the cp. I get the full 1000 almost every time. I'm on an old x86 box, # psrinfo -vp The physical processor has 1 virtual processor (0) x86 (GenuineIntel family 6 model 8 step 10 clock 867 MHz) Intel(r) Pentium(r) III ... with 512 Mb RAM, 40 Gb disk, and using a 1 Gb UFS for testing. > When I run your script and do a cp on a 1000 page file, > I get about 128 segvn_fault calls for the cp. I've now tried it on an Ultra 5 and get 132 segvn_fault()s every time, similar to you. This is quite different indeed! > This is a much more reasonable number, since cp > is mmap-ing the file, and the file system code > should be faulting in multiple pages at a time. Thanks - so a read ahead style algorithm for these faults isn't a far fetched idea at all. :) segvn_fault appears to be triggered for 1 page - I need to find the part where it triggers multiple pages. > For instance, if the file system brings in 56k, (14 pages > on my amd64 box), and my disk is reasonably fast, > by the time cp gets a bit into the first 56k, I suspect > that all of the data is in memory and there is no > trapping into the kernel at all until the next 56k > needs to be read in. That would make sense. In this case (testing here anyway) it's not going near disk for reading (only writing the destination file), x86, extended device statistics r/s w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device 0.0 74.0 0.0 3999.8 0.0 0.1 0.0 0.9 0 6 c0d0 sparc, extended device statistics r/s w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device 0.0 65.0 0.0 7995.6 23.6 1.8 363.7 27.7 88 90 c0t0d0 So, considering both systems undercount expected faults - one fault must be triggering some form of "read ahead" from the page cache, not disk. I'm thinking the path is somthing like, ufs_getpage_ra -> pvn_read_kluster -> page_create_va -> (read many?) > (I guess I am assuming the hat > layer is setting up pte's as the pages are brought in, > not as cp is accessing them). Yep - and that sort of problem would be the very thing that throws a spanner in the works. If it always waited for cp to access them, then I'd have consistant events to trace... Thanks Max! :) Brendan _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org