Dear Rezwanul,

I have been using this fix for quite some time without any visible ill
effects on the other keys or the system in general.
Of course it would be necessary to get feedback from other dell users.

Thanks.

On Thu, Jun 3, 2010 at 11:16 PM, Islam Amer gmail.com> wrote:

The first util-linux-ng 2.18 release candidate is available at

ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/v2.18/

Feedback and bug reports, as always, are welcomed.

Karel

Util-linux-ng 2.18 Release Notes
================================

The util-linux-ng package does not contain rdev(8), ramsize(8),
vidmode(8) and rootflags(8) utils anymore.

Release highlights
------------------

libmount:
- this NEW LIBRARY is designed to be used in low-level utils like
mount(8) and /sbin/mount. helpers as well as in some other
projects.

- the library API is still officially unstable. The library provides
fstab, mtab and mountinfo parser, routines for work with parsed
data and mount options, mtab locking, etc. The high-level API for
mount(2) is planned for the next major release. For more details see:
http://thread.gmane.org/gmane.linux.utilities.util-linux-ng/3239

Hello.

I've got a.. difficult issue here, and am asking if anyone else
has some expirence or information about it.

Production environment (database). Machine with an Adaptec
RAID SCSI controller, 6 drives in raid10 array, XFS filesystem
and Oracle database on top of it (with - hopefully - proper
sunit/swidth).

Upgrading kernel from 2.6.27 to 2.6.32, and users starts screaming
about very bad performance. Iostat reports increased I/O latencies,
I/O time increases from ~5ms to ~30ms. Switching back to 2.6.27,
and everything is back to normal (or, rather, usual).

I tried testing I/O with a sample program which performs direct random
I/O on a given device, and all speeds are actually better in .32
compared with .27, except of random concurrent r+w test, where .27
gives a bit more chances to reads than .32. Looking at the synthetic
tests I'd expect .32 to be faster, but apparently it is not.

Replying to a very old email :-)

On Wed, Nov 25, 2009 at 12:15 AM, Andi Kleen firstfloor.org> wrote:

Submit Name:Address:Age:Sex:Occupation:Tel:Country

On Mon, 2010-06-07 at 17:48 +0800, Peter Zijlstra wrote:

I tested this patch and it works well for pre-defined events.

Lin Ming

On Sun, Jun 06, 2010 at 09:38:16PM +0530, Sachin Sant wrote:

Hi,

This is my first post to the group, please excuse me, If I unknowingly miss to follow writing ethics.

Proposal/Need:

I was working on providing accurate process usage support, and writing a kernel module,
I configured cpu-core-unhalted-event and configured LVT (local vector table) with NMI (non-maskable interrupt), and surprisingly Oprofile stopped working,
Then I realized, that set_nmi_call back just overwrites nmi_callback function pointer.

My proposal/idea/thinking is;
have a kernel module which accepts NMI registration from any kernel component, and providing support to the the any kernel service which basically need to service NMI.
It may not only supports this, but also can provide central infrastructure which has capabilities such as granting MSR (model specific register) access to the the modules, which may avoid potential clash of MSRs (e.g. two modules are trying to configure same MSR), control NMI registration-unregisteration events etc..

I am not sure, whether this is a good idea or bad idea, but I thought it adds flexibility and some value addition in kernel,
and I find this place precisely right to post this idea.

Any feedback/suggestions/additions would be appreciated.

Regards,
Oza.

Hi,

This is my first post to the group, please excuse me, If I unknowingly miss to follow writing ethics.

Proposal/Need:

I was working on providing accurate process usage support, and writing a kernel module,
I configured cpu-core-unhalted-event and configured LVT (local vector table) with NMI (non-maskable interrupt), and surprisingly Oprofile stopped working,
Then I realized, that set_nmi_call back just overwrites nmi_callback function pointer.

My proposal/idea/thinking is;
have a kernel module which accepts NMI registration from any kernel component, and providing support to the the any kernel service which basically need to service NMI.
It may not only supports this, but also can provide central infrastructure which has capabilities such as granting MSR (model specific register) access to the the modules, which may avoid potential clash of MSRs (e.g. two modules are trying to configure same MSR), control NMI registration-unregisteration events etc..

I am not sure, whether this is a good idea or bad idea, but I thought it adds flexibility and some value addition in kernel,
and I find this place precisely right to post this idea.

Any feedback/suggestions/additions would be appreciated.

Regards,
Oza.

I finally got a chance last week to visit the topic of direct reclaim
avoiding the writing out pages. As it came up during discussions the last
time, I also had a stab at making the VM writing ranges of pages instead
of individual pages. I am not proposing for merging yet until I want to see
what people think of this general direction and if we can agree on if this
is the right one or not.

To summarise, there are two big problems with page reclaim right now. The
first is that page reclaim uses a_op->writepage to write a back back
under the page lock which is inefficient from an IO perspective due to
seeky patterns. The second is that direct reclaim calling the filesystem
splices two potentially deep call paths together and potentially overflows
the stack on complex storage or filesystems. This series is an early draft
at tackling both of these problems and is in three stages.

The first 4 patches are a forward-port of trace points that are partly
based on trace points defined by Larry Woodman but never merged. They trace
parts of kswapd, direct reclaim, LRU page isolation and page writeback. The
tracepoints can be used to evaluate what is happening within reclaim and
whether things are getting better or worse. They do not have to be part of
the final series but might be useful during discussion.