[OpenAFS-devel] more on the 2.2.18pre17 SMP cpu hog/etc.

Nathan Neulinger nneul@umr.edu
Fri, 01 Dec 2000 17:03:07 -0600


Derek Atkins wrote:
> 
> Are you sure the kernel sees all 512MB?  Also, could you possibly been
> having problems with slow disk I/O?  Or maybe somebody slipped a
> "sleep(2)" in there while you weren't looking? ;)


cessna(48)> hdparm -Tt /dev/hda

/dev/hda:
 Timing buffer-cache reads:   128 MB in  1.26 seconds =101.59 MB/sec
 Timing buffered disk reads:  64 MB in  3.79 seconds =16.89 MB/sec
cessna(49)> cat /proc/meminfo 
        total:    used:    free:  shared: buffers:  cached:
Mem:  529260544 382590976 146669568 39456768 147603456 144662528
Swap: 542826496        0 542826496
MemTotal:    516856 kB
MemFree:     143232 kB
MemShared:    38532 kB
Buffers:     144144 kB
Cached:      141272 kB
SwapTotal:   530104 kB
SwapFree:    530104 kB

It's got me stumped... I've never seen behavior like this before. I'm
thinking of instrumenting heavily the afs_call.c file where it handles
the AFSOP_CACHEINODE call, but figured I'd ask around first.

A sleep(2) would be lovely, but that wouldn't mesh with the symptom -
it's not that it's taking a long time, it's that it's killing the whole
machine's performance and in turn taking forever. Now - something like a
in-kernel busy-wait-loop-for-2-seconds might jive (i.e. something that
causes the kernel to not context-switch), and in fact, there are some
loops in the afs_call.c code that I was going to look over for that.

I just realized that I'm actually running the 1.0 release at home (plus
that alloc patch), I need to do a cvs checkout and try it again, but I
don't believe anything significant has changed in cvs for 2.2.x. 

-- Nathan

> -derek
> 
> "Neulinger, Nathan R." <nneul@umr.edu> writes:
> 
> > scroll down about 15 lines... 512MB.
> >
> > -- Nathan
> >
> > > -----Original Message-----
> > > From: Derek Atkins [mailto:warlord@MIT.EDU]
> > > Sent: Friday, December 01, 2000 4:31 PM
> > > To: Nathan Neulinger
> > > Cc: Patrick J. Hennessey; openafs-devel@openafs.org
> > > Subject: Re: [OpenAFS-devel] more on the 2.2.18pre17 SMP cpu hog/etc.
> > >
> > >
> > > How much RAM is in your home machine?
> > >
> > > -derek
> > >
> > > Nathan Neulinger <nneul@umr.edu> writes:
> > >
> > > > "Patrick J. Hennessey" wrote:
> > > > >
> > > > > On Thu, 30 Nov 2000, Nathan Neulinger wrote:
> > > > > > After a very long time, it actually finished and mounted /afs.
> > > > >
> > > > > The first time afsd runs it has to create a bunch of
> > > inode cache entries
> > > > > and dirs.  This is noticably inefficient, especially if
> > > you configure a
> > > > > large cache.  If you wait it out afsd will start much
> > > quicker the second
> > > > > time around.
> > > >
> > > > I've been running AFS for years. The cache was already
> > > built, and even
> > > > if it hadn't been, the cache creation has never (on any
> > > platform I've
> > > > used afs on - even slow p.o.s. aix boxes) driven the
> > > machine into the
> > > > ground. Starting afs on my home box manually results in X being
> > > > virtually unusable - and this is on a dual-850-piii w/
> > > 512MB of memory.
> > > >
> > > > In any case, the slowdown occurs AFTER the cache files are created,
> > > > during the second pass through the cache activating the
> > > cache inodes -
> > > > where it potentially creates/checks the contents of the
> > > cache files.
> > > >
> > > > BTW, this is on reiserfs, I've got linux x86 machines at work that
> > > > create 350 MB afs caches from scratch (empty filesystem) in
> > > a matter of
> > > > 30-40 SECONDS. This slowdown resulted in afsd w/ a 3.5MB afs cache
> > > > taking 10 MINUTES to start.
> > > >
> > > > -- Nathan
> > > >
> > > > ------------------------------------------------------------
> > > > Nathan Neulinger                       EMail:  nneul@umr.edu
> > > > University of Missouri - Rolla         Phone: (573) 341-4841
> > > > CIS - Systems Programming                Fax: (573) 341-4216
> > > > _______________________________________________
> > > > OpenAFS-devel mailing list
> > > > OpenAFS-devel@openafs.org
> > > > https://lists.openafs.org/mailman/listinfo.cgi/openafs-devel
> > >
> > > --
> > >        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> > >        Member, MIT Student Information Processing Board  (SIPB)
> > >        URL: http://web.mit.edu/warlord/      PP-ASEL      N1NWH
> > >        warlord@MIT.EDU                        PGP key available
> > > _______________________________________________
> > > OpenAFS-devel mailing list
> > > OpenAFS-devel@openafs.org
> > > https://lists.openafs.org/mailman/listinfo.cgi/openafs-devel
> > >
> 
> --
>        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>        Member, MIT Student Information Processing Board  (SIPB)
>        URL: http://web.mit.edu/warlord/      PP-ASEL      N1NWH
>        warlord@MIT.EDU                        PGP key available

-- 


------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul@umr.edu
University of Missouri - Rolla         Phone: (573) 341-4841
CIS - Systems Programming                Fax: (573) 341-4216