1. 08 12月, 2006 1 次提交
  2. 01 10月, 2006 1 次提交
    • J
      [PATCH] csa: convert CONFIG tag for extended accounting routines · 8f0ab514
      Jay Lan 提交于
      There were a few accounting data/macros that are used in CSA but are #ifdef'ed
      inside CONFIG_BSD_PROCESS_ACCT.  This patch is to change those ifdef's from
      CONFIG_BSD_PROCESS_ACCT to CONFIG_TASK_XACCT.  A few defines are moved from
      kernel/acct.c and include/linux/acct.h to kernel/tsacct.c and
      include/linux/tsacct_kern.h.
      Signed-off-by: NJay Lan <jlan@sgi.com>
      Cc: Shailabh Nagar <nagar@watson.ibm.com>
      Cc: Balbir Singh <balbir@in.ibm.com>
      Cc: Jes Sorensen <jes@sgi.com>
      Cc: Chris Sturtivant <csturtiv@sgi.com>
      Cc: Tony Ernst <tee@sgi.com>
      Cc: Guillaume Thouvenin <guillaume.thouvenin@bull.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      8f0ab514
  3. 30 9月, 2006 1 次提交
  4. 15 7月, 2006 1 次提交
  5. 01 7月, 2006 1 次提交
  6. 28 6月, 2006 2 次提交
  7. 26 6月, 2006 4 次提交
    • K
      [PATCH] pacct: none-delayed process accounting accumulation · 77787bfb
      KaiGai Kohei 提交于
      In current 2.6.17 implementation, signal_struct refered from task_struct is
      used for per-process data structure.  The pacct facility also uses it as a
      per-process data structure to store stime, utime, minflt, majflt.  But those
      members are saved in __exit_signal().  It's too late.
      
      For example, if some threads exits at same time, pacct facility has a
      possibility to drop accountings for a part of those threads.  (see, the
      following 'The results of original 2.6.17 kernel') I think accounting
      information should be completely collected into the per-process data structure
      before writing out an accounting record.
      
      This patch fixes this matter.  Accumulation of stime, utime, minflt and majflt
      are done before generating accounting record.
      
      [mingo@elte.hu: fix acct_collect() siglock bug found by lockdep]
      Signed-off-by: NKaiGai Kohei <kaigai@ak.jp.nec.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      77787bfb
    • K
      [PATCH] pacct: avoidance to refer the last thread as a representation of the process · f6ec29a4
      KaiGai Kohei 提交于
      When pacct facility generate an 'ac_flag' field in accounting record, it
      refers a task_struct of the thread which died last in the process.  But any
      other task_structs are ignored.
      
      Therefore, pacct facility drops ASU flag even if root-privilege operations are
      used by any other threads except the last one.  In addition, AFORK flag is
      always set when the thread of group-leader didn't die last, although this
      process has called execve() after fork().
      
      We have a same matter in ac_exitcode.  The recorded ac_exitcode is an exit
      code of the last thread in the process.  There is a possibility this exitcode
      is not the group leader's one.
      f6ec29a4
    • K
      [PATCH] pacct: add pacct_struct to fix some pacct bugs. · 0e464814
      KaiGai Kohei 提交于
      The pacct facility need an i/o operation when an accounting record is
      generated.  There is a possibility to wake OOM killer up.  If OOM killer is
      activated, it kills some processes to make them release process memory
      regions.
      
      But acct_process() is called in the killed processes context before calling
      exit_mm(), so those processes cannot release own memory.  In the results, any
      processes stop in this point and it finally cause a system stall.
      0e464814
    • M
      [PATCH] Remove unecessary NULL check in kernel/acct.c · 11e64757
      Matt Helsley 提交于
      copy_process() appears to be the only caller of acct_clear_integrals() and
      does not pass in NULL task pointers.  Remove the unecessary check.
      Signed-off-by: NMatt Helsley <matthltc@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      11e64757
  8. 23 6月, 2006 1 次提交
  9. 01 4月, 2006 1 次提交
    • K
      [PATCH] Fix pacct bug in multithreading case. · bb231fe3
      KaiGai Kohei 提交于
      I noticed a bug on the process accounting facility.  In multi-threading
      process, some data would be recorded incorrectly when the group_leader dies
      earlier than one or more threads.  The attached patch fixes this problem.
      
      See below.  'bugacct' is a test program that create a worker thread after 4
      seconds sleeping, then the group_leader dies soon.  The worker thread
      consume CPU/Memory for 6 seconds, then exit.  We can estimate 10 seconds as
      etime and 6 seconds as stime + utime.  This is a sample program which the
      group_leader dies earlier than other threads.
      
      The results of same binary execution on different kernel are below.
      -- accounted records --------------------
               |   btime  | utime | stime | etime | minflt | majflt |   comm  |
      original | 13:16:40 |  0.00 |  0.00 |  6.10 |    171 |      0 | bugacct |
       patched | 13:20:21 |  5.83 |  0.18 | 10.03 |  32776 |      0 | bugacct |
      (*) bugacct allocates 128MB memory, thus 128MB / 4KB = 32768 of minflt is
          appropriate.
      
      -- Test results in original kernel ------
      $ date; time -p ./bugacct
      Tue Mar 28 13:16:36 JST 2006  <- But pacct said btime is 13:16:40
      real 10.11                    <- But pacct said etime is 6.10
      user 5.96                     <- But pacct said utime is 0.00
      sys 0.14                      <- But pacct said stime is 0.00
      $
      -- Test results in patched kernel -------
      $ date; time -p ./bugacct
      Tue Mar 28 13:20:21 JST 2006
      real 10.04
      user 5.83
      sys 0.19
      $
      
      In the original 2.6.16 kernel, pacct records btime, utime, stime, etime and
      minflt incorrectly.  In my opinion, this problem is caused by an assumption
      that group_leader dies last.
      
      The following section calculates process running time for etime and btime.
      But it means running time of the thread that dies last, not process.  The
      start_time of the first thread in the process (group_leader) should be
      reduced from uptime to calculate etime and btime correctly.
      
         ---- do_acct_process() in kernel/acct.c:
         /* calculate run_time in nsec*/
         do_posix_clock_monotonic_gettime(&uptime);
         run_time = (u64)uptime.tv_sec*NSEC_PER_SEC + uptime.tv_nsec;
         run_time -= (u64)current->start_time.tv_sec*NSEC_PER_SEC
                                         + current->start_time.tv_nsec;
         ----
      
      The following section calculates stime and utime of the process.
      But it might count the utime and stime of the group_leader duplicatly
      and ignore the utime and stime of the thread dies last, when one or
      more threads remain after group_leader dead.
      The ac_utime should be calculated as the sum of the signal->utime
      and utime of the thread dies last. The ac_stime should be done also.
      
         ---- do_acct_process() in kernel/acct.c:
         jiffies = cputime_to_jiffies(cputime_add(current->group_leader->utime,
                                                  current->signal->utime));
         ac.ac_utime = encode_comp_t(jiffies_to_AHZ(jiffies));
         jiffies = cputime_to_jiffies(cputime_add(current->group_leader->stime,
                                                  current->signal->stime));
         ac.ac_stime = encode_comp_t(jiffies_to_AHZ(jiffies));
         ----
      
      The part of the minflt/majflt calculation has same problem.
      This patch solves those problems, I think.
      
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      bb231fe3
  10. 12 1月, 2006 1 次提交
  11. 07 1月, 2006 1 次提交
  12. 08 11月, 2005 1 次提交
    • A
      [PATCH] saner handling of auto_acct_off() and DQUOT_OFF() in umount · 7b7b1ace
      Al Viro 提交于
      The way we currently deal with quota and process accounting that might
      keep vfsmount busy at umount time is inherently broken; we try to turn
      them off just in case (not quite correctly, at that) and
      
        a) pray umount doesn't fail (otherwise they'll stay turned off)
        b) pray nobody doesn anything funny just as we turn quota off
      
      Moreover, LSM provides hooks for doing the same sort of broken logics.
      
      The proper way to deal with that is to introduce the second kind of
      reference to vfsmount.  Semantics:
      
       - when the last normal reference is dropped, all special ones are
         converted to normal ones and if there had been any, cleanup is done.
       - normal reference can be cloned into a special one
       - special reference can be converted to normal one; that's a no-op if
         we'd already passed the point of no return (i.e.  mntput() had
         converted special references to normal and started cleanup).
      
      The way it works: e.g. starting process accounting converts the vfsmount
      reference pinned by the opened file into special one and turns it back
      to normal when it gets shut down; acct_auto_close() is done when no
      normal references are left.  That way it does *not* obstruct umount(2)
      and it silently gets turned off when the last normal reference to
      vfsmount is gone.  Which is exactly what we want...
      
      The same should be done by LSM module that holds some internal
      references to vfsmount and wants to shut them down on umount - it should
      make them special and security_sb_umount_close() will be called exactly
      when the last normal reference to vfsmount is gone.
      
      quota handling is even simpler - we don't use normal file IO anymore, so
      there's no need to hold vfsmounts at all.  DQUOT_OFF() is done from
      deactivate_super(), where it really belongs.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      7b7b1ace
  13. 30 10月, 2005 1 次提交
    • H
      [PATCH] mm: rss = file_rss + anon_rss · 4294621f
      Hugh Dickins 提交于
      I was lazy when we added anon_rss, and chose to change as few places as
      possible.  So currently each anonymous page has to be counted twice, in rss
      and in anon_rss.  Which won't be so good if those are atomic counts in some
      configurations.
      
      Change that around: keep file_rss and anon_rss separately, and add them
      together (with get_mm_rss macro) when the total is needed - reading two
      atomics is much cheaper than updating two atomics.  And update anon_rss
      upfront, typically in memory.c, not tucked away in page_add_anon_rmap.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      4294621f
  14. 11 9月, 2005 1 次提交
  15. 08 9月, 2005 1 次提交
    • P
      [PATCH] largefile support for accounting · 6c9c0b52
      Peter Staubach 提交于
      There is a problem in the accounting subsystem in the kernel can not
      correctly handle files larger than 2GB.  The output file containing the
      process accounting data can grow very large if the system is large enough
      and active enough.  If the 2GB limit is reached, then the system simply
      stops storing process accounting data.
      
      Another annoying problem is that once the system reaches this 2GB limit,
      then every process which exits will receive a signal, SIGXFSZ.  This signal
      is generated because an attempt was made to write beyond the limit for the
      file descriptor.  This signal makes it look like every process has exited
      due to a signal, when in fact, they have not.
      
      The solution is to add the O_LARGEFILE flag to the list of flags used to
      open the accounting file.  The rest of the accounting support is already
      largefile safe.
      
      The changes were tested by constructing a large file (just short of 2GB),
      enabling accounting, and then running enough commands to cause the
      accounting data generated to increase the size of the file to 2GB.  Without
      the changes, the file grows to 2GB and the last command run in the test
      script appears to exit due a signal when it has not.  With the changes,
      things work as expected and quietly.
      
      There are some user level changes required so that it can deal with
      largefiles, but those are being handled separately.
      Signed-off-by: NPeter Staubach <staubach@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      6c9c0b52
  16. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4