fa.linux.kernel
  Home FAQ Contact Sign in
fa.linux.kernel only
 
Advanced search
June 2010
motuwethfrsasuw
 123456 22
78910111213 23
14151617181920 24
21222324252627 25
282930     26
2010
 Jan   Feb   Mar   Apr 
 May   Jun   Jul   Aug 
 Sep   Oct   Nov   Dec 
2010 2008 2007 2006
total
fa.linux.kernel Profile…
RELATED GROUPS

POPULAR GROUPS

more...

 Up
  Re: Dell Studio 1555 eject key does not work ( small patch to fix included )         


Author: Islam Amer
Date: Jun 8, 2010 03:58

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:
> Hello,
>
> I suspected the same about dell_new_hk_type, but I am confused that
> the rest of the fn keys work just fine out of the...
Show full article (3.13Kb)
no comments
  [ANNOUNCE] util-linux-ng v2.18-rc1         


Author: Karel Zak
Date: Jun 8, 2010 03:46

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
Show full article (18.80Kb)
1 Comment
  xfs, aacraid 2.6.27 => 2.6.32 results in 6 times slowdown         


Author: Michael Tokarev
Date: Jun 8, 2010 03:01

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.
Show full article (2.10Kb)
no comments
  Re: [RFC] Using "page credits" as a solution for common thrashing scenarios         


Author: Eyal Lotem
Date: Jun 8, 2010 02:45

Replying to a very old email :-)

On Wed, Nov 25, 2009 at 12:15 AM, Andi Kleen firstfloor.org> wrote:
> Eyal Lotem gmail.com> writes:
>
> Replying to an old email.
>
>>   * I think it is wrong for the kernel to evict the 15 pages of the bash,
>>     xterm, X server's working set, as an example, in order for a
>>     misbehaving process to have 1000015 instead of 1000000 pages in its
>>     working set. EVEN if that misbehaving process is accessing its working
>>     set far more aggressively.
>
> One problem in practice tends to be that it's hard to realiably detect
> that a process is misbehaving. The 1000000 page process might be your
> critical database, while the 15 page process is something very
> unimportant.
Show full article (1.34Kb)
no comments
  Congrat,891,934.00GBP has been awarded to you.         


Author: MSOFT
Date: Jun 8, 2010 02:26

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
no comments
  Re: [PATCH -tip] perf, x86: Make a second write to performance counter if needed         


Author: Lin Ming
Date: Jun 8, 2010 02:20

On Mon, 2010-06-07 at 17:48 +0800, Peter Zijlstra wrote:
> On Thu, 2010-06-03 at 01:23 +0400, Cyrill Gorcunov wrote:
>> On Netburst PMU we need a second write to a performance counter
>> due to cpu erratum.
>>
>> A simple flag test instead of alternative instructions was choosen
>> because wrmsrl is already a macro and if virtualization is turned
>> on will need an additional wrapper call which is more expencise.
>>
>> nb: we should propably switch to jump-labels as only this facility
>> reach the mainline.
>
> OK. Thanks Cyrill.

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

Lin Ming
Show full article (0.87Kb)
no comments
  Re: 2.6.35-rc2: GPF while executing libhugetlbfs tests on x86_64         


Author: Mel Gorman
Date: Jun 8, 2010 02:18

On Sun, Jun 06, 2010 at 09:38:16PM +0530, Sachin Sant wrote:
> While executing libhugetlbfs tests against 2.6.35-rc2 on
> a x86_64 box came across the following GPF
>
> eneral protection fault: 0000 [#1] SMP
> last sysfs file: /sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map
> CPU 3
> Modules linked in: ipv6 mperf fuse loop dm_mod sr_mod cdrom usb_storage sg i2c_piix4 rtc_cmos bnx2 k8temp pcspkr serio_raw mptctl i2c_core rtc_core rtc_lib shpchp button pci_hotplug usbhid hid ohci_hcd ehci_hcd sd_mod crc_t10dif usbcore edd ext3 jbd fan thermal processor thermal_sys hwmon mptsas mptscsih mptbase scsi_transport_sas scsi_mod
>
> Pid: 20232, comm: autotest Not tainted 2.6.35-rc2-autotest #1 Server Blade/BladeCenter LS21 -[79716AA]-
> RIP: 0010:[] [] _raw_spin_lock+0x9/0x20
> RSP: 0018:ffff880126e43d88 EFLAGS: 00010202
> RAX: 0000000000010000 RBX: 0720072007200720 RCX: 0000000000000000
> RDX: 0000000000000011 RSI: ffff8801293a7470 RDI: 0720072007200720
> RBP: ffff880126e43d88 R08: ffff8801279df270 R09: 09f911029d74e35b
> R10: 09f911029d74e35b R11: dead000000100100 R12: ffff8801278cae00
> R13: 0720072007200710 R14: ffff8801297e71f8 R15: 0000000000000000
> FS: 00007f461d6866f0(0000) GS:ffff880006180000(0000) knlGS:0000000055731b00
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f461d45a7b8 CR3: 0000000001713000 CR4: 00000000000006e0 ...
Show full article (3.69Kb)
no comments
  [PROPOSAL - FIRST POST] NMI & register clash handling infrastructure         


Author: Oza Oza
Date: Jun 8, 2010 02:11

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
no comments
  [PROPOSAL - FIRST POST] NMI & register clash handling infrastructure         


Author: Oza Oza
Date: Jun 8, 2010 02:04

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
no comments
  [RFC PATCH 0/6] Do not call ->writepage[s] from direct reclaim and use a_ops->writepages() where possible         


Author: Mel Gorman
Date: Jun 8, 2010 02:03

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.
Show full article (3.83Kb)
6 Comments
1 2 3 4 5 6 7 8 9