Bug 451063 - backport RUSAGE_THREAD support
Summary: backport RUSAGE_THREAD support
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.2
Hardware: All
OS: Linux
high
medium
Target Milestone: rc
: ---
Assignee: Jerome Marchand
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks: 483701 484214 485920
TreeView+ depends on / blocked
 
Reported: 2008-06-12 16:56 UTC by Issue Tracker
Modified: 2018-10-20 02:43 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
: 484214 (view as bug list)
Environment:
Last Closed: 2009-09-02 08:26:31 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2009:1243 0 normal SHIPPED_LIVE Important: Red Hat Enterprise Linux 5.4 kernel security and bug fix update 2009-09-01 08:53:34 UTC

Description Issue Tracker 2008-06-12 16:56:36 UTC
Escalated to Bugzilla from IssueTracker

Comment 1 Issue Tracker 2008-06-12 16:56:37 UTC
It used to be that getrusage(RUSAGE_SELF...) returned the information from just that kernel task and not all the child tasks which were often threads. Thus if you had a process where the parent slept while all the work was done in the threads getrusage(RUSAGE_SELF...) would be very wrong. This was fixed and now getrusage(RUSAGE_SELF...) returns the correct value for the process. However, we would also like the ability to inquire about a thread's usage. This was added upstream by a RH engineer. Can we backport it into RHEL5.

http://kerneltrap.org/mailarchive/linux-kernel/2008/1/19/582809
This event sent from IssueTracker by jwest  [SEG - Feature Request]
 issue 185356

Comment 2 Issue Tracker 2008-06-12 16:56:38 UTC
Who is the customer?

LLNL

What is the exact nature of the problem trying to be solved with this
request?

Backport RUSAGE_THREAD support from upstream into a future RHEL5 kernel
update.

What, if any, business requirements are satisfied by this request? (What
is the use case context?)

LLNL works with complex code every day, and tools such as getrusage are
helpful in diagnosing problems and gathering statistics resource usage.

List the functional requirement(s) for performing the action(s) that are
not presently possible. Please focus on describing the problem related
requirements without projecting any specific solution.

It used to be that getrusage(RUSAGE_SELF...) returned the information from
just that kernel task and not all the child tasks which were often threads.
Thus if you had a process where the parent slept while all the work was
done in the threads getrusage(RUSAGE_SELF...) would be very wrong. This
was fixed and now getrusage(RUSAGE_SELF...) returns the correct value for
the process. However, we would also like the ability to inquire about a
thread's usage. 

Each functional requirement must have clear acceptance criteria so Red Hat
understands what success looks like. If test cases can be provided this
would be even more ideal (bonus points for RHTS test cases).

With this patch in place, calls to getrusage() will now return correct
information about a process.

What is the desired release vehicle to satisfy these requirements?

Minor release...RHEL5.3 or 5.4 would be desirable


What package(s) are affected by this RFE? (List "new" if new technology
is likely to be required) kernel package

Who is the sales sponsor?
Nathan Jones

What is the Red Hat business opportunity with this customer?

Having this sort of functionality won't just benefit LLNL.  It will come
in handy for all of the DoE, as well as any customers that write and
diagnose their own complex codes.

What is the status and risk to the contract if this RFE is not satisfied?

We could lose out to a competitor that would be more willing to implement
this functionality in their distribution.


Issue escalated to SEG - Feature Request by: kbaxley.
kbaxley assigned to issue for LLNL (HPC).
Category set to: Kernel
Internal Status set to 'Waiting on SEG'
Status set to: Waiting on Tech

This event sent from IssueTracker by jwest  [SEG - Feature Request]
 issue 185356

Comment 8 RHEL Program Management 2009-02-16 15:13:41 UTC
Updating PM score.

Comment 9 Don Zickus 2009-02-23 20:00:56 UTC
in kernel-2.6.18-132.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5

Please do NOT transition this bugzilla state to VERIFIED until our QE team
has sent specific instructions indicating when to do so.  However feel free
to provide a comment indicating that this fix has been verified.

Comment 13 Chris Ward 2009-07-03 18:03:39 UTC
~~ Attention - RHEL 5.4 Beta Released! ~~

RHEL 5.4 Beta has been released! There should be a fix present in the Beta release that addresses this particular request. Please test and report back results here, at your earliest convenience. RHEL 5.4 General Availability release is just around the corner!

If you encounter any issues while testing Beta, please describe the issues you have encountered and set the bug into NEED_INFO. If you encounter new issues, please clone this bug to open a new issue and request it be reviewed for inclusion in RHEL 5.4 or a later update, if it is not of urgent severity.

Please do not flip the bug status to VERIFIED. Only post your verification results, and if available, update Verified field with the appropriate value.

Questions can be posted to this bug or your customer or partner representative.

Comment 17 errata-xmlrpc 2009-09-02 08:26:31 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2009-1243.html


Note You need to log in before you can comment on or make changes to this bug.