
<!DOCTYPE html>

<html>

  <head>


    <meta http-equiv="content-type" content="text/html; charset=UTF-8">

  </head>

  <body>

    <p>All,</p>

    <p>An update on the previous lustre-discuss post.  The closing of

      the first file after writing, dumping from cache, and reopening

      with O_RDONLY, does make it immune to the stat()s from another

      client node.</p>

    <p>Now to the real question I have concerning the Lustre caching for

      the reproducer program.  I have changed the reproducer to :</p>

    <p>1: write the first file, sim.dat.A.</p>

    <p>2: force a memory dump of the OSCs ofA by doing O_DIRECT reads of

      the first stripe block on each OSC.  ( a trick I recently learned

      )</p>

    <p>3: close the fd for A and reopen with only O_RDONLY.</p>

    <p>4: read A.</p>

    <p>5: write the larger second file, sim.dat.B</p>

    <p>6: using the same fd, without closing B, read B forwards and

      backwards.</p>

    <p>7: close both files.</p>

    <p>This can all be see in this first image.  </p>

    <p>Why do the OSCs forA retain their memory even though the data is

      used/touched only once, while the OSCs for B are fighting for

      caching memory and their data is used/touched 3 times?</p>

    <p><img moz-do-not-send="false"

        src="cid:part1.4CdQXkQA.8LPOO9s0@iodoctors.com"

alt="https://www.dropbox.com/scl/fi/flpvi9dnvftbtpjquleef/3461_fpa.png?rlkey=ux7zko8igh6loosrfs05ryb1c&st=mtpixhyy&dl=0"

        width="1067" height="695"></p>

    <p>Another plot of interest relating to this run is the amount of

      memory for filePages on each node(socket) of the system.  This

      happens to be an 8 node system. When A is read back in it is

      placed on nodes 1,2, and 4.  While B is later fighting for caching

      memory, it also has filePages on node 4.  How can A hang on to the

      memory when its pages's LRU is certainly less than or equal to

      those for B.  The memory behavior can't be a node thing either as

      both files are on node 4 for much of the run, but A never gets

      pushed out of node 4.  I should also point out that the aggregate

      of the filePages on the 8 nodes maps directly to the cached memory

      from meminfo.  Not sure why it was decided to call the node thing

      filePages and the meminfo thing cached in /proc.</p>

    <p><img moz-do-not-send="false"

        src="cid:part2.rzX0Yf5M.sXTOd0II@iodoctors.com"

alt="https://www.dropbox.com/scl/fi/gcpbct21e0knx5d420njo/3461_nodemem.png?rlkey=c47nl06a5hoqswh62ivx9uxdh&st=za8ec97b&dl=0"

        width="1052" height="683"></p>

    <p><br>

    </p>

  </body>

</html>