Fix some RCU problem pointed out by Paul McKenney of IBM. These are:
The wholesale move of the command receivers list into a new list was
not safe because the list will point to the new tail during a
traversal, so the traversal will never end on a reader if this happens
during a read.
Memory
Kill OF? sparc does not want that IMO, how else should I return to
the 'ok' prompt?
PowerPC kills OF because it really has to,
No it doesn't. It has to on some (very common, heh) subarchs.
that's one of numerous
reasons that it started sucking the device tree into a kernel copy
early in
This patch is in support of the IPMI driver. I have tested this
with the IPMI driver changes coming in the next patch.
Add a list_splice_init_rcu() function to splice an RCU-protected list
into another list. This takes the sync function as an argument, so
one would do something like:
Hi,
I would like to set up a directory with only links to the source files
I use during the building of the kernel. The development ide/editor
will target this directory instead of main source tree. The benefit of this
is that I don't need to bother about files that are not included
by the
therefore you can't let multiple CPUs call
into OFW at one time. You must use some kind of locking mechanism,
and that locking mechanism is not simple because it has to not just
stop the other cpus, it has to be able to stop the other cpus yet
still allow them to receive SMP cross-calls from the
> > > > No, it won't need 2 transitions - just an extra function call,
> > > > so it won't hurt performance - it would improve performance.
> > > >
> > > > ib_uverbs_req_notify_cq would call
> > > >
> > > > ib_uverbs_req_notify_cq()
> > > > {
> > > >
On Wed, Jan 03, 2007 at 07:34:59PM +0530, Gautham R Shenoy wrote:
>
> > handle-cpu_lock_acquire-and-cpu_lock_release-in-workqueue_cpu_callback.patch
>
> Again, this one ensures that workqueue_mutex is taken/released on
> CPU_LOCK_ACQUIRE/CPU_LOCK_RELEASE events in the cpuhotplug callback
>
> > > I've run this code with mthca and didn't notice any performance
> > > degradation, but I wasn't specifically measuring cq_poll overhead in a
> > > tight loop...
> >
> > We were speaking about ib_req_notify_cq here, actually, not cq poll.
> > So what was tested?
> >
>
> Sorry, I meant
On Wed, Jan 03, 2007 at 09:00:58AM -0600, James Bottomley wrote:
> However, I was wondering if there might be a different way around this.
> We can't really walk all the user mappings because of the locks, but
> could we store the user flush hints in the page (or a related
> structure)? On parisc
On Wed, 2007-01-03 at 17:00 +0200, Michael S. Tsirkin wrote:
> > >
> > > No, it won't need 2 transitions - just an extra function call,
> > > so it won't hurt performance - it would improve performance.
> > >
> > > ib_uverbs_req_notify_cq would call
> > >
> > > ib_uverbs_req_notify_cq()
> > >
On Wed, 2007-01-03 at 17:02 +0200, Michael S. Tsirkin wrote:
> > I've run this code with mthca and didn't notice any performance
> > degradation, but I wasn't specifically measuring cq_poll overhead in a
> > tight loop...
>
> We were speaking about ib_req_notify_cq here, actually, not cq poll.
>
Hopefully this patch should solve steve's issue too.
Sure looks like it.
o Older binutils required explicit flags to mark a section allocatable
and executable(AX). Newer binutils automatically mark a section AX if
the name starts with .text.
More exactly, since 2.15 more section names
> I've run this code with mthca and didn't notice any performance
> degradation, but I wasn't specifically measuring cq_poll overhead in a
> tight loop...
We were speaking about ib_req_notify_cq here, actually, not cq poll.
So what was tested?
--
MST
-
To unsubscribe from this list: send the
Hi everybody.
After my last mails to this issue (btw: anything new in the meantime? I
received no replys..) I wrote again to nvidia and AMD...
This time with some more success.
Below is the answer from Mr. Friedman to my mail. He says that he wasn't
able to reproduce the problem and asks for a
On Wed, 3 Jan 2007, Jiri Slaby wrote:
> Robert P. J. Day wrote:
> [...]
> > index fd82411..b3932e5 100644
> > --- a/include/asm-m68k/sun3_pgalloc.h
> > +++ b/include/asm-m68k/sun3_pgalloc.h
> > @@ -36,12 +36,11 @@ static inline void pte_free(struct page *page)
> > static inline pte_t
> >
> > No, it won't need 2 transitions - just an extra function call,
> > so it won't hurt performance - it would improve performance.
> >
> > ib_uverbs_req_notify_cq would call
> >
> > ib_uverbs_req_notify_cq()
> > {
> > ib_set_cq_udata(cq, udata)
> >
On Wed, 2007-01-03 at 14:16 +, Russell King wrote:
> On Tue, Jan 02, 2007 at 04:20:58PM -0800, David Miller wrote:
> > From: James Bottomley <[EMAIL PROTECTED]>
> > Date: Tue, 02 Jan 2007 17:34:18 -0600
> >
> > > Erm ... for a device driver, if we're preparing to do I/O on the page
> > >
On Fri, 2006-12-29 at 15:01 +0100, Martin Michlmayr wrote:
> Yes, I agree. I'm CCing the linux-mm list in hope that someone can
> review your patch. In the meantime, I've asked the Debian LSB folks to
> verify that your patch fixes the LSB problem.
I am running the complete lsb-runtime-test
> > >
> > > It seems all Chelsio needs is to pass in a consumer index - so, how about
> > > a new
> > > entry point? Something like void set_cq_udata(struct ib_cq *cq, struct
> > > ib_udata *udata)?
> > >
> >
> > Adding a new entry point would hurt chelsio's user mode performance if
> > if
> > > @@ -1373,7 +1374,7 @@ int ib_peek_cq(struct ib_cq *cq, int wc_
> > > static inline int ib_req_notify_cq(struct ib_cq *cq,
> > > enum ib_cq_notify cq_notify)
> > > {
> > > - return cq->device->req_notify_cq(cq, cq_notify);
> > > + return
From: Serge E. Hallyn <[EMAIL PROTECTED]>
Subject: [RFC] [PATCH 1/1] container: define a namespace container subsystem
Here's a stab at a namespace container subsystem based on
Paul Menage's containers patch, just to experiment with
how semantics suit what we want.
A few things we'll want to
Robert P. J. Day wrote:
> Replace the small number of combinations of __get_free_page() plus a
> call to memset(...,0,PAGE_SIZE) with a single call to
> get_zeroed_page().
>
> Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
>
> ---
>
> all of the following simplifications *look* valid,
At least the Keyspan USA-19HS USB-to-serial converter supports
two different configurations, one where the input endpoints
have interrupt transfer type and one where they are bulk endpoints.
The default UHCI configuration uses the interrupt input endpoints.
The keyspan driver, OTOH, assumes that
Ingo Molnar a écrit :
looks good to me in principle. The size of the patch is scary - is there
really no simpler way?
Humf, in fact, for the 64-bit part, I've followed the rule of the existing
64-bit code in futex.c, which consists of duplicating all the functions which
can not be kept
Daniel,
On Sat, Dec 23, 2006 at 07:53:47AM -0800, Daniel Walker wrote:
> On Fri, 2006-12-22 at 02:43 -0800, Stephane Eranian wrote:
> > Hello,
> >
> >
> > The perfmon subsystems needs to compute per-CPU duration. It is using
> > sched_clock() to provide this information. However, it seems they
> > @@ -1373,7 +1374,7 @@ int ib_peek_cq(struct ib_cq *cq, int wc_
> > static inline int ib_req_notify_cq(struct ib_cq *cq,
> >enum ib_cq_notify cq_notify)
> > {
> > - return cq->device->req_notify_cq(cq, cq_notify);
> > + return cq->device->req_notify_cq(cq,
> cmov is effectively the same cost as a compare and jump, in both cases
> the cpu needs to do a prediction, and on a mispredict, restart.
On a P4 it appears to be slower than compare/jump in most cases
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Wed, 3 Jan 2007 14:53:26 +0100, Adrian Bunk wrote:
> On Wed, Jan 03, 2007 at 09:46:45AM +0530, Vivek Goyal wrote:
> >
> > o i386 kernel reboots instantly if compiled with binutils older than
> > 2.6.15.
>
> Should that have been "2.15"?
>
> And is the following perhaps the same issue?
>
>
On Wed, Jan 03, 2007 at 02:53:26PM +0100, Adrian Bunk wrote:
> On Wed, Jan 03, 2007 at 09:46:45AM +0530, Vivek Goyal wrote:
> >
> > o i386 kernel reboots instantly if compiled with binutils older than
> > 2.6.15.
>
> Should that have been "2.15"?
>
Yes Adrian, it should be 2.15 instead. My
Rainer Weikusat <[EMAIL PROTECTED]> writes:
[...]
>> And, we don't want to panic() for such a trivial thing. Just abort the
>> probe sequence at most, but never shut down the machine for an odd
>> device that we find.
>
> I actually thought about that this morning: Considering the path this
>
On Tue, Jan 02, 2007 at 04:20:58PM -0800, David Miller wrote:
> From: James Bottomley <[EMAIL PROTECTED]>
> Date: Tue, 02 Jan 2007 17:34:18 -0600
>
> > Erm ... for a device driver, if we're preparing to do I/O on the page
> > something must have made the user caches coherent ... that can't be
> >
Hi Andrew,
Sorry, I am yet to check out Venki's and Oleg's patches as I
just returned from Vacation.
On Tue, Jan 02, 2007 at 04:27:27PM -0800, Andrew Morton wrote:
>
> I have a mental note that these:
>
> extend-notifier_call_chain-to-count-nr_calls-made.patch
>
On Wed, Jan 03, 2007 at 05:32:16AM -0800, Arjan van de Ven wrote:
> On Wed, 2007-01-03 at 12:44 +, Alan wrote:
> > > > fixed. At that point an i686 kernel would contain i686 instructions and
> > > > actually run on all i686 processors ending all the i586 pain for most
> > > > users and
Replace the small number of combinations of __get_free_page() plus a
call to memset(...,0,PAGE_SIZE) with a single call to
get_zeroed_page().
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
all of the following simplifications *look* valid, but i'm happy to
be convinced otherwise.
On Wed, Jan 03, 2007 at 01:33:31PM +0100, Miklos Szeredi wrote:
> High probability is all you have. Cosmic radiation hitting your
> computer will more likly cause problems, than colliding 64bit inode
> numbers ;)
Some of us have machines designed to cope with cosmic rays, and would be
On Wed, Jan 03, 2007 at 09:46:45AM +0530, Vivek Goyal wrote:
>
> o i386 kernel reboots instantly if compiled with binutils older than
> 2.6.15.
Should that have been "2.15"?
And is the following perhaps the same issue?
Subject: kernel immediately reboots instead of booting
References :
On Mon, 2007-01-01 at 21:01 -0800, Jesse Barnes wrote:
> Using MMCONFIG for PCI config space access is simply an optimization, not
> a requirement. Therefore, when it can't be used, there's no need for
> KERN_ERR level message. This patch makes the message a KERN_INFO instead
> to reduce some of
On Tue, 2007-01-02 at 10:36 +, Alan wrote:
> On Mon, 1 Jan 2007 21:01:38 -0800
> Jesse Barnes <[EMAIL PROTECTED]> wrote:
>
> > Using MMCONFIG for PCI config space access is simply an optimization, not
> > a requirement. Therefore, when it can't be used, there's no need for
>
> Some hardware
On Wed, 2007-01-03 at 12:44 +, Alan wrote:
> > > fixed. At that point an i686 kernel would contain i686 instructions and
> > > actually run on all i686 processors ending all the i586 pain for most
> > > users and distributions.
> >
> > Could you explain why CMOV is pointless now? Are there
On Tue, Jan 02, 2007 at 02:38:13PM -0700, Dan Williams ([EMAIL PROTECTED])
wrote:
> Would you have time to comment on the approach I have taken to
> implement a standard asynchronous memcpy interface? It seems it would
> be a good complement to what you are proposing. The entity that
>
On Mon, 2007-01-01 at 23:28 +, Anton Altaparmakov wrote:
> Hi Linus and Andrew,
>
> Please apply below patch which exports invalidate_mapping_pages() to
> modules. It makes no sense to me to export invalidate_inode_pages() and
> not invalidate_mapping_pages() and I actually need
>
On Mon, 25 Dec 2006, Florin Iucha wrote:
> I left the machine to run the diff and when I came back, the USB
> keyboard was unresponsive although the USB mice plugged in the hub built
> into the keyboard were working fine. I was able to ssh into the box,
> capture the dmesg and reboot.
On Sun, 31 Dec 2006, Arjan van de Ven wrote:
> So... yes I fully agree with you that it's worth looking at the
> memset( , PAGE_SIZE) users. If they are page aligned, yes absolutely
> make it a clear_page(), I think that's a very good idea. However
> also please check if they've been very
Adrian,
On Sat, Dec 23, 2006 at 12:40:15PM +0100, Adrian Bunk wrote:
> >
> > If you look at the perfmon-new-base patch, you'll see a base.diff patch
> > which
> > includes this one. I am slowly getting rid of this requirement by pushing
> > those "infrastructure patches" to mainline so that the
Hello!
> High probability is all you have. Cosmic radiation hitting your
> computer will more likly cause problems, than colliding 64bit inode
> numbers ;)
No.
If you assign 64-bit inode numbers randomly, 2^32 of them are sufficient
to generate a collision with probability around 50%.
Hi all :)
I've noticed that, even if I say NO to initramfs (and even ramdisk
support), the make process wants to GEN usr/initramfs_data.cpio.gz by
running the scripts/gen_initramfs_list.sh script.
Why is that script run no matter the initramfs support? Looks like
it only depends on
Hi!
> > > > > the use of a good hash function. The chance of an accidental
> > > > > collision is infinitesimally small. For a set of
> > > > >
> > > > > 100 files: 0.03%
> > > > >1,000,000 files: 0.03%
> > > >
> > > > I do not think we want to play with
* Pierre Peiffer <[EMAIL PROTECTED]> wrote:
> Hi,
>
> First, thanks Ingo for your comments on my previous mail from
> december. I've taken all your remarks into account.
>
> The 64-bit and compat versions have been implemented and tested. The
> glibc part has also been updated and the x86_64
> > fixed. At that point an i686 kernel would contain i686 instructions and
> > actually run on all i686 processors ending all the i586 pain for most
> > users and distributions.
>
> Could you explain why CMOV is pointless now? Are there any benchmarks
> proving that?
Take a look at the recent
Trond Myklebust wrote:
> On Sun, 2006-12-31 at 16:25 -0500, Halevy, Benny wrote:
>> Trond Myklebust wrote:
>>>
>>> On Thu, 2006-12-28 at 15:07 -0500, Halevy, Benny wrote:
Mikulas Patocka wrote:
> BTW. how does (or how should?) NFS client deal with cache coherency if
> filehandles
> > > > the use of a good hash function. The chance of an accidental
> > > > collision is infinitesimally small. For a set of
> > > >
> > > > 100 files: 0.03%
> > > >1,000,000 files: 0.03%
> > >
> > > I do not think we want to play with probability like this. I
Hi,
First, thanks Ingo for your comments on my previous mail from december.
I've taken all your remarks into account.
The 64-bit and compat versions have been implemented and tested.
The glibc part has also been updated and the x86_64 version is now implemented
too.
Here after is the updated
Pablo Sebastian Greco wrote:
> First of all, thanks for everything, and my excuses if I'm doing
> anything wrong, this is my first lkml mail, but I've read all the faq,
> so should be OK.
> This is the machine with the problem:
>
> Intel ServerBoard S5000VSA
> Dual Core Xeon 2.66 (Intel(R)
Apologies if I'm posting to the wrong list - the lksctp lists seem to be a
bit dead these days and a bit of Googling seemed to inidicate that SCTP
developemnt discussions might have moved here.
I'm running under the 2.6.16.1 kernel and have an intermittent problem
with the SCTP stack. Having
Implement card lock/unlock operation, using the MMC_LOCK_UNLOCK command.
Signed-off-by: Carlos Eduardo Aguiar <[EMAIL PROTECTED]>
Signed-off-by: Anderson Lizardo <[EMAIL PROTECTED]>
Signed-off-by: Anderson Briglia <[EMAIL PROTECTED]>
Index: linux-linus-2.6/drivers/mmc/mmc.h
Implement key retention operations.
Signed-off-by: Carlos Eduardo Aguiar <[EMAIL PROTECTED]>
Signed-off-by: Anderson Lizardo <[EMAIL PROTECTED]>
Signed-off-by: Anderson Briglia <[EMAIL PROTECTED]>
Index: linux-linus-2.6/drivers/mmc/Kconfig
Hi all,
I believe this code is following the latest Russel's comments.
Regards,
Anderson Briglia
---> cut here <
Implement MMC password force erase, remove password, change password,
unlock card and assign password operations. It uses the sysfs mechanism
to send commands to the MMC
When a card is locked, only commands from the "basic" and "lock card" classes
are accepted. To be able to use the other commands, the card must be unlocked
first.
This patch prevents the device drivers from probing the locked cards. Device
probing must be triggered sometime later to make the
Hi!
> > > the use of a good hash function. The chance of an accidental
> > > collision is infinitesimally small. For a set of
> > >
> > > 100 files: 0.03%
> > >1,000,000 files: 0.03%
> >
> > I do not think we want to play with probability like this. I mean...
> >
Grzegorz Kulewski wrote:
On Wed, 3 Jan 2007, Alan wrote:
The proper fix for all of this mess is to fix the gcc compiler suite to
actually generate i686 code when told to use i686. CMOV is an optional
i686 extension which gcc uses without checking. In early PIV days it made
sense but on modern
o Currently synchronize_tsc_ap() is of type __init. It is called by
smp_callin() which is of type __cpuinit. So synchronize_tsc_ap()
should be of type __cpuinit.
o Modpost generates warnings for i386 if CONFIG_RELOCATABLE=y and
CONFIG_HOTPLUG_CPU=y
WARNING: vmlinux - Section mismatch:
o Older binutils (older than 2.6.15) require explicit flags to be set
for section. (if a section has been defined using "section" directive).
Otherwise a section which should have been allocatable and executable
(AX) will not have properties as per intention.
o I had put a patch in -mm
o MODPOST generates warning for i386 if kernel is compiled with
CONFIG_RELOCATABLE=y
WARNING: vmlinux - Section mismatch: reference to .init.data: from .data
between 'this_cpu' (at offset 0xc05194d0) and 'cpuinfo_op'
o this_cpu pointer should be of type __cpuinitdata.
Signed-off-by: Vivek
o MODPOST generates warning for i386 if kernel is compiled with
CONFIG_RELOCATABLE=y
WARNING: vmlinux - Section mismatch: reference to .init.text:startup_32_smp
from .data between 'trampoline_data' (at offset 0xc0519cf8) and 'boot_gdt'
o trampoline code/data can go into init section is CPU
Greg KH <[EMAIL PROTECTED]> writes:
> On Tue, Jan 02, 2007 at 07:16:54PM +0100, Rainer Weikusat wrote:
>> At least the Keyspan USA-19HS USB-to-serial converter supports
>> two different configurations, one where the input endpoints
>> have interrupt transfer type and one where they are bulk
On Tue, Jan 02, 2007 at 03:32:01PM +, Sid Boyce wrote:
> Jarek Poplawski wrote:
...
> >If you could send full ifconfig, route -n (or ip route
> >if you use additional tables) and tcpdump (all packets)
> >from both boxes while pinging each other and a few words
> >how it is connected (other
[Re-added lkml to the CC list, please don't drop anything from CC]
On 2007.01.03 17:39:48 +0800, [EMAIL PROTECTED] wrote:
> Hi!
>
> Thanks very much for your clear explanation !
>
> I have another question about irq_exit(), hope you can help me.
>
> void irq_exit(void)
> {
>
On Wed, 3 Jan 2007, Alan wrote:
The proper fix for all of this mess is to fix the gcc compiler suite to
actually generate i686 code when told to use i686. CMOV is an optional
i686 extension which gcc uses without checking. In early PIV days it made
sense but on modern processors CMOV is so
> That's a good suggestion. Earlier C3s didn't have cmov so it's
> not entirely unlikely that cmov in C3-2 is broken in some cases.
> Configuring for P5MMX or 486 should be good safe alternatives.
The proper fix for all of this mess is to fix the gcc compiler suite to
actually generate i686 code
On Wednesday 03 January 2007 10:18, Jan Beulich wrote:
> Add a load option to intel-rng to allow skipping the FWH detection,
> necessary in case the BIOS has locked read-only the firmware hub space.
> Also prevent any attempt to write to firmware space if it cannot be
> write enabled (apparently
Not much luck with the 4th patch, I guess it's too big. I've gzip
attached it now, with the description inlined.
---
Nick writes:
This is a patch to perform block device plugging explicitly in the submitting
process context rather than implicitly by the block device.
There are several
On Wed, Jan 03 2007, Tomas Carnecky wrote:
> Jens Axboe wrote:
> > diff --git a/Documentation/RCU/checklist.txt
> > b/Documentation/RCU/checklist.txt
> > index f4dffad..36d6185 100644
> > --- a/Documentation/RCU/checklist.txt
> > +++ b/Documentation/RCU/checklist.txt
> > @@ -259,3 +259,16 @@ over
Adrian Bunk wrote:
> This patch contains the scheduled removal of the eepro100 driver.
>
I'm sorry to disturb the schedule, but I'm not sure right now if this
pending issue of the e100 was meanwhile solved or declared a non-issue:
http://lkml.org/lkml/2006/9/8/105
Auke, can you confirm that it
Don't force CONFIG_SWIOTLB on when not actually needed (i.e. HP_ZX1 and
SGI_SN2).
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
--- linux-2.6.20-rc3/arch/ia64/Kconfig 2007-01-02 15:41:38.0 +0100
+++ 2.6.20-rc3-ia64-swiotlb-opt/arch/ia64/Kconfig 2006-12-22
16:44:57.0
On 2007.01.03 16:23:28 +0800, [EMAIL PROTECTED] wrote:
> Hello all!
>
> Kernel version : 2.6.18
> Arch : i386
>
> With the following conditions, it is possible that softirqs are
> executed in a interrupt context rather than process one
> 1) CONFIG_4KSTACKS > ON
> That means the dedicated
Add a load option to intel-rng to allow skipping the FWH detection,
necessary in case the BIOS has locked read-only the firmware hub space.
Also prevent any attempt to write to firmware space if it cannot be
write enabled (apparently caused hangs on some systems not having an
FWH and thus also not
Jens Axboe wrote:
> diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt
> index f4dffad..36d6185 100644
> --- a/Documentation/RCU/checklist.txt
> +++ b/Documentation/RCU/checklist.txt
> @@ -259,3 +259,16 @@ over a rather long period of time, but improvements are
>
On Tue, 2 Jan 2007, Chuck Ebbert wrote:
> > [ 336.476284] EIP is at device_cmp+0x1b/0x2e [ipt_MASQUERADE]
> > [ 336.476344] eax: de6d4000 ebx: ecx: d944b7a0 edx: dd664d48
> > [ 336.476404] esi: 0004 edi: 1f58 ebp: 03eb esp: de6d4e90
> > [ 336.476464] ds: 007b
On Tue, 2007-01-02 at 16:23 -0300, Horst H. von Brand wrote:
> Bernd Petrovitsch <[EMAIL PROTECTED]> wrote:
> [...]
> > I don't know about others but I wouldn't write an offer with a fixed
> > price for "look into assembler dumps, reverse engineer it and find an
> > infringement on a list of given
Hello all!
Kernel version : 2.6.18
Arch : i386
With the following conditions, it is possible that softirqs are
executed in a interrupt context rather than process one
1) CONFIG_4KSTACKS > ON
That means the dedicated IRQ stack is used for hardirq handler
2) there exist some Hard IRQ
Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>
Acked-by: Jens Axboe <[EMAIL PROTECTED]>
---
Documentation/RCU/checklist.txt | 13 +
Documentation/RCU/rcu.txt |6 --
Documentation/RCU/torture.txt | 15 +--
Documentation/RCU/whatisRCU.txt |3 +++
On Wed, Jan 03 2007, Andrew Morton wrote:
> On Wed, 3 Jan 2007 08:48:28 +0100
> Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > This is a patch to perform block device plugging explicitly in the
> > submitting
> > process context rather than implicitly by the block device.
>
> I don't think anyone
On Tue, 2 Jan 2007 23:59:23 -0800
Ravikiran G Thirumalai <[EMAIL PROTECTED]> wrote:
> The following patches do just that. The first patch is preparatory in nature
> and the second one changes the x86_64 implementation of spin_lock_irq.
> Patch passed overnight runs of kernbench and dbench on 4
On Wed, 3 Jan 2007 08:48:28 +0100
Jens Axboe <[EMAIL PROTECTED]> wrote:
> This is a patch to perform block device plugging explicitly in the submitting
> process context rather than implicitly by the block device.
I don't think anyone will regret the passing of
Implement interrupt enabling while spinning for lock for spin_lock_irq
Signed-off by: Pravin B. Shelar <[EMAIL PROTECTED]>
Signed-off by: Ravikiran Thirumalai <[EMAIL PROTECTED]>
Signed-off by: Shai Fultheim <[EMAIL PROTECTED]>
Index: linux-2.6.20-rc1/include/asm-x86_64/spinlock.h
There seems to be no good reason for spin_lock_irq to disable interrupts
while spinning. Zwane Mwaikambo had an implementation couple of years ago,
and the only objection seemed to be concerns about buggy code using
spin_lock_irq whilst interrupts disabled
http://lkml.org/lkml/2004/5/26/87
There seems to be no good reason for spin_lock_irq to disable interrupts
while spinning. Zwane Mwaikambo had an implementation couple of years ago,
and the only objection seemed to be concerns about buggy code using
spin_lock_irq whilst interrupts disabled
http://lkml.org/lkml/2004/5/26/87
Implement interrupt enabling while spinning for lock for spin_lock_irq
Signed-off by: Pravin B. Shelar [EMAIL PROTECTED]
Signed-off by: Ravikiran Thirumalai [EMAIL PROTECTED]
Signed-off by: Shai Fultheim [EMAIL PROTECTED]
Index: linux-2.6.20-rc1/include/asm-x86_64/spinlock.h
On Wed, 3 Jan 2007 08:48:28 +0100
Jens Axboe [EMAIL PROTECTED] wrote:
This is a patch to perform block device plugging explicitly in the submitting
process context rather than implicitly by the block device.
I don't think anyone will regret the passing of
On Tue, 2 Jan 2007 23:59:23 -0800
Ravikiran G Thirumalai [EMAIL PROTECTED] wrote:
The following patches do just that. The first patch is preparatory in nature
and the second one changes the x86_64 implementation of spin_lock_irq.
Patch passed overnight runs of kernbench and dbench on 4 way
On Wed, Jan 03 2007, Andrew Morton wrote:
On Wed, 3 Jan 2007 08:48:28 +0100
Jens Axboe [EMAIL PROTECTED] wrote:
This is a patch to perform block device plugging explicitly in the
submitting
process context rather than implicitly by the block device.
I don't think anyone will regret
Signed-off-by: Paul E. McKenney [EMAIL PROTECTED]
Acked-by: Jens Axboe [EMAIL PROTECTED]
---
Documentation/RCU/checklist.txt | 13 +
Documentation/RCU/rcu.txt |6 --
Documentation/RCU/torture.txt | 15 +--
Documentation/RCU/whatisRCU.txt |3 +++
4
Hello all!
Kernel version : 2.6.18
Arch : i386
With the following conditions, it is possible that softirqs are
executed in a interrupt context rather than process one
1) CONFIG_4KSTACKS ON
That means the dedicated IRQ stack is used for hardirq handler
2) there exist some Hard IRQ
On Tue, 2007-01-02 at 16:23 -0300, Horst H. von Brand wrote:
Bernd Petrovitsch [EMAIL PROTECTED] wrote:
[...]
I don't know about others but I wouldn't write an offer with a fixed
price for look into assembler dumps, reverse engineer it and find an
infringement on a list of given patents so
On Tue, 2 Jan 2007, Chuck Ebbert wrote:
[ 336.476284] EIP is at device_cmp+0x1b/0x2e [ipt_MASQUERADE]
[ 336.476344] eax: de6d4000 ebx: ecx: d944b7a0 edx: dd664d48
[ 336.476404] esi: 0004 edi: 1f58 ebp: 03eb esp: de6d4e90
[ 336.476464] ds: 007b es:
Jens Axboe wrote:
diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt
index f4dffad..36d6185 100644
--- a/Documentation/RCU/checklist.txt
+++ b/Documentation/RCU/checklist.txt
@@ -259,3 +259,16 @@ over a rather long period of time, but improvements are
always
Add a load option to intel-rng to allow skipping the FWH detection,
necessary in case the BIOS has locked read-only the firmware hub space.
Also prevent any attempt to write to firmware space if it cannot be
write enabled (apparently caused hangs on some systems not having an
FWH and thus also not
On 2007.01.03 16:23:28 +0800, [EMAIL PROTECTED] wrote:
Hello all!
Kernel version : 2.6.18
Arch : i386
With the following conditions, it is possible that softirqs are
executed in a interrupt context rather than process one
1) CONFIG_4KSTACKS ON
That means the dedicated IRQ stack
On Wed, Jan 03 2007, Tomas Carnecky wrote:
Jens Axboe wrote:
diff --git a/Documentation/RCU/checklist.txt
b/Documentation/RCU/checklist.txt
index f4dffad..36d6185 100644
--- a/Documentation/RCU/checklist.txt
+++ b/Documentation/RCU/checklist.txt
@@ -259,3 +259,16 @@ over a rather
Not much luck with the 4th patch, I guess it's too big. I've gzip
attached it now, with the description inlined.
---
Nick writes:
This is a patch to perform block device plugging explicitly in the submitting
process context rather than implicitly by the block device.
There are several
201 - 300 of 556 matches
Mail list logo
