* Nick Piggin <[EMAIL PROTECTED]> wrote:
> 1/13
>
ugh, has this been tested? It needs the patch below.
Ingo
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
--- linux/kernel/sched.c.orig
+++ linux/kernel/sched.c
@@ -2704,11 +2704,11 @@ need_resched_nonpreemptible:
schedstat_i
Here is a cleaned up version of my 2.6.8 kernel patch.
This patch allows to use floppy drive in non-DMA mode on PegasosPPC and
AmigaOne machines. To use it:
1. Do not build floppy driver as a module, link it statically. Transferring
parameters to it from insmod is still problematic, at least
See attached changelog. I'm too slack to post a patch tonight.
Please do a
bk pull bk://gkernel.bkbits.net/netdev-2.6
This will update the following files:
drivers/net/bagetlance.c| 1368 -
include/linux/dp83840.h | 41
Documentati
On Wed, 2005-02-23 at 11:11 -0800, Jay Lan wrote:
> Guillaume Thouvenin wrote:
> > It's what I'm proposing. The problem is to be alerted when a new process
> > is created in order to add it in the correct group of processes if the
> > parent belongs to one (or several) groups. The notification can
13/13
Do some basic initial tuning.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
Index: linux-2.6/include/asm-x86_64/topology.h
===
--- linux-2.6.orig/include/asm-x86_64/topology.h 2005-02-24 17:39:07.615911131 +1100
+++ linux-2.6
Dominik Brodowski wrote:
@@ -184,6 +186,7 @@
dev_list = link;
client_reg.dev_info = &dev_info;
+ client_reg.Attributes = INFO_IO_CLIENT | INFO_CARD_SHARE;
That's not needed any longer for 2.6.
So who wants to send the incremental update patch? :)
Jeff
-
To unsubscri
11/13
Reimplement the balance on exec balancing to be sched-domains aware. Use
this to also do balance on fork balancing. Make x86_64 do balance on fork
over the NUMA domain.
The problem that the non sched domains aware blancing became apparent on
dual core, multi socket opterons. What we want is
10/13
Remove the very aggressive idle stuff that has recently gone into
2.6 - it is going against the direction we are trying to go. Hopefully
we can regain performance through other methods.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
Index: linux-2.6/include/asm-i386/topology.h
=
12/13
Add SCHEDSTAT statistics for sched-balance-fork.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
Index: linux-2.6/include/linux/sched.h
===
--- linux-2.6.orig/include/linux/sched.h 2005-02-24 17:39:07.616911007 +1100
+++ linux
8/13
Do CPU load averaging over a number of different intervals. Allow
each interval to be chosen by sending a parameter to source_load
and target_load. 0 is instantaneous, idx > 0 returns a decaying average
with the most recent sample weighted at 2^(idx-1). To a maximum of 3
(could be easily incr
9/13
Do less affine wakeups. We're trying to reduce dbt2-pgsql idle time
regressions here... make sure we don't don't move tasks the wrong way
in an imbalance condition. Also, remove the cache coldness requirement
from the calculation - this seems to induce sharp cutoff points where
behaviour will
When you start writing the PCI root bridge driver you'll run into the
AGP drivers that are already attached to the bridge. I was surprised
by this since I expected AGP to be attached to the AGP bridge but now
I learned that it is a root bridge function.
An ISA LPC bridge driver would be nice too.
7/13
Fix up active load balancing a bit so it doesn't get called when it shouldn't.
Reset the nr_balance_failed counter at more points where we have found
conditions to be balanced. This reduces too aggressive active balancing seen
on some workloads.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]
5/13
Cleanup find_busiest_group a bit. New sched-domains code
means we can't have groups without a CPU.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
Index: linux-2.6/kernel/sched.c
===
--- linux-2.6.orig/kernel/sched.c 2005-02-24
4/13
Fix up a few small warts in the periodic multiprocessor rebalancing
code.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
Index: linux-2.6/kernel/sched.c
===
--- linux-2.6.orig/kernel/sched.c 2005-02-24 17:31:28.431609701 +1100
3/13
I have an updated userspace parser for this thing, if you
are still keeping it on your website.
Move balancing fields into struct sched_domain, so we can get more
useful results on systems with multiple domains (eg SMT+SMP, CMP+NUMA,
SMP+NUMA, etc).
Signed-off-by: Nick Piggin <[EMAIL PROTEC
2/13
John Hawkes explained the problem best:
A large number of processes that are pinned to a single CPU results
in every other CPU's load_balance() seeing this overloaded CPU as
"busiest", yet move_tasks() never finds a task to pull-migrate. This
condition occurs during module unload, but ca
1/13
Some fixes for unsynchronised TSCs. A task's timestamp may have been set
by another CPU. Although we try to adjust this correctly with the
timestamp_last_tick field, there is no guarantee this will be exactly right.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
Index: linux-2.6/kernel/sche
Hi,
I hope that you can include the following set of CPU scheduler
patches in -mm soon, if you have no other significant performance
work going on.
There are some fairly significant changes, with a few basic aims:
* Improve SMT behaviour
* Improve CMP behaviour, CMP/NUMA scheduling (ie. Opteron)
On Thu, 2005-02-24 at 01:45 -0500, Jon Smirl wrote:
> On Thu, 24 Feb 2005 01:22:01 -0500, Adam Belay <[EMAIL PROTECTED]> wrote:
> > For the past couple weeks I have been reorganizing the PCI subsystem to
> > better utilize the driver model. Specifically, the bus detection code
> > is now using a s
> @@ -184,6 +186,7 @@
> dev_list = link;
>
> client_reg.dev_info = &dev_info;
> + client_reg.Attributes = INFO_IO_CLIENT | INFO_CARD_SHARE;
That's not needed any longer for 2.6.
Dominik
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
"Chad N. Tindel" <[EMAIL PROTECTED]> wrote:
>
> > `xterm' is waiting for the other CPU to schedule a kernel thread (which is
> > bound to that CPU). Once that kernel thread has done a little bit of work,
> > `xterm' can terminate.
> >
> > But kernel threads don't run with realtime policy, so your
On Thu, 24 Feb 2005 01:22:01 -0500, Adam Belay <[EMAIL PROTECTED]> wrote:
> For the past couple weeks I have been reorganizing the PCI subsystem to
> better utilize the driver model. Specifically, the bus detection code
> is now using a standard PCI driver. It turns out to be a major
What about
On Wed, 2005-02-23 at 14:41 +0300, Evgeniy Polyakov wrote:
> > Please assume that > originally written for> will always be listening.
> >
> > > > What happened to the idea of sending an on/off message down the netlink
> > > > socket?
> > ...
> > Arrange for the userspace daemon to send a message t
On Thu, 2005-02-24 at 04:56 +, Hugh Dickins wrote:
> On Wed, 23 Feb 2005, Lee Revell wrote:
> > On Wed, 2005-02-23 at 20:53 +, Hugh Dickins wrote:
> > > On Wed, 23 Feb 2005, Hugh Dickins wrote:
> > > > Please replace by new patch below, which I'm now running through
> > > > lmbench.
> > >
Quoting Linus Torvalds ([EMAIL PROTECTED]):
>
>
> Hey, I hoped -rc4 was the last one, but we had some laptop resource
> conflicts, various ppc TLB flush issues, some possible stack overflows in
> networking and a number of other details warranting a quick -rc5 before
> the final 2.6.11.
>
> This
On Wed, Feb 23, 2005 at 08:18:08PM -0800, Linus Torvalds wrote:
>
>
> Hey, I hoped -rc4 was the last one, but we had some laptop resource
> conflicts, various ppc TLB flush issues, some possible stack overflows in
> networking and a number of other details warranting a quick -rc5 before
> the fin
Hi all,
For the past couple weeks I have been reorganizing the PCI subsystem to
better utilize the driver model. Specifically, the bus detection code
is now using a standard PCI driver. It turns out to be a major
undertaking, as the PCI probing code is closely tied into a lot of other
PCI compon
>This time it's really supposed to be a quickie, so people who can,
>please check it out, and we'll make the real 2.6.11 asap.
Out of diskspace on kernel.org?
http://www.kernel.org/pub/linux/kernel/v2.6/testing/
[...]
patch-2.6.11-rc5.bz2 23-Feb-2005 20:20 14
patch-2.6.11-rc5.b
i8k.c | 117 ++
1 files changed, 117 insertions(+)
Index: dtor/drivers/char/i8k.c
===
--- dtor.orig/drivers/char/i8k.c
+++ dtor/drivers/char/i8k.c
@@ -22,6 +22,7 @@
===
I8K: use module_{init|exit} instead of old style #ifdef MODULE
code, some formatting changes.
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
i8k.c | 149 --
===
I8K: Change to use stock dmi infrastructure instead of homegrown
parsing code. The driver now requres box's DMI data to match
list of supported models so driver can be safely compiled-in
by default without fear of i
===
I8K: Change proc code to use seq_file.
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
i8k.c | 64 ++--
1 files changed, 22 insertions(+), 42 deletions(-)
Index
Hi,
here are some changes that freshen I8K driver (Dell Inspiron/Latitude
platform driver). The patches have been tested on Inspiron 8100.
i8k-lindent.patch
- pass the driver through Lindent to comply with CondingStyle requirements
(4 spaces vs. TAB indentation)
i8k-use-dmi.patch
- use standar
===
I8K: pass through Lindent to change 4 spaces identation to TABs
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
i8k.c | 954 +-
1 files changed, 477 insertion
1. Rationale
Currently the Linux kernel implements a hierachical page table utilizing 4
layers. Architectures that have less layers may cause the kernel to not
generate code for certain layers. However, there are other means for mmu
to describe page tables to the system. For example t
On Thu, 2005-02-24 at 05:12 +, Hugh Dickins wrote:
> On Thu, 24 Feb 2005, Nick Piggin wrote:
> > OK after sleeping on it, I'm warming to your way.
> >
> > I don't think it makes something like David's modifications any
> > easier, but mine didn't go a long way to that end either. And
> > bein
On Thu, 24 Feb 2005, Nick Piggin wrote:
> Hugh Dickins wrote:
>
> > I'm inlining pmd and pud levels, but not pte and pgd levels.
>
> OK - that's probably sufficient for debugging. There is only so
> much that can go wrong in the middle levels...
Yes, that was my thinking.
> how does it look
>
On Wed, 23 Feb 2005, Ammar T. Al-Sayegh wrote:
> - Original Message - From: "Hugh Dickins" <[EMAIL PROTECTED]>
> > though quite possibly you cannot afford
> > such experiments on this server, and will revert to 2.4 for now.
>
> The problem is that my server is already in production
> mode.
> But the other side of the coin is that a SCHED_FIFO userspace task
> presumably has extreme latency requirements, so it doesn't *want* to be
> preempted by some routine kernel operation. People would get irritated if
> we were to do that.
Just to follow up a bit. People writing apps that run a
> `xterm' is waiting for the other CPU to schedule a kernel thread (which is
> bound to that CPU). Once that kernel thread has done a little bit of work,
> `xterm' can terminate.
>
> But kernel threads don't run with realtime policy, so your userspace app
> has permanently starved that kernel thr
Mark Lord wrote:
Minor patch for new 2.6.xx sata_qstor driver attached,
as per Alexey's fine-toothed comb! :)
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
I had to apply this manually, since your mailer "corrupts" the patch by
encoding text/plain as base64. Please fix your mailer...
The ideal i
Hi,
Can you please let me know, what all files does the OS look into to
load modules?
I see the following messages during boot rather installation:
==
Finished bus probing
modules to insert tg3 aic79xx
==
which files does the OS look into to load tg3 and aic79xx after
finishing bus probin
Dear all
I am new to this place, Please correct me if i am wrong.
Before console_init, printk is just filling up the printk buffer.
After console_init, will the message print out immediately?
best regard
Mike,Lee
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
t
On Wed, 23 Feb 2005, Lee Revell wrote:
> On Wed, 2005-02-23 at 20:53 +, Hugh Dickins wrote:
> > On Wed, 23 Feb 2005, Hugh Dickins wrote:
> > > Please replace by new patch below, which I'm now running through lmbench.
> >
> > That second patch seems fine, and I see no lmbench regression from it
Reformats printk()s, comments, labels and other cosmetic strings in
the orinoco driver. Also moves, removes, and adds ratelimiting in
some places. Behavioural changes are trivial/cosmetic only. This
reduces the cosmetic/trivial differences between the current kernel
version, and the CVS version
Add descrptions to module parameters in the orinoco driver, and also
add permissions to allow them to be exported in sysfs.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: working-2.6/drivers/net/wireless/orinoco.c
===
--- wor
Apply some cleanups to the low-level orinoco handling code in
hermes.[ch]. This cleans up some error handling code, corrects an
error code to something more accurate, and also increases a timeout
value. This last can (when the hardware plays up) cause long delays
with spinlocks held, which is bad
applied patches 1-14 to netdev-2.6. We'll let it sit there for a bit,
for testing and such. (netdev-2.6 gets auto-propagated to -mm)
Thanks for your patience and perserverance.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [E
Ron Peterson <[EMAIL PROTECTED]> wrote:
>
> I would like to better understand ext2/3's performance characteristics.
>
> I'm specifically interested in how ext2/3 will handle a /var/spool/mail
> directory w/ ~6000 mbox format inboxes, handling approx 1GB delivered as
> 75,000 messages daily. Virtu
Hey, I hoped -rc4 was the last one, but we had some laptop resource
conflicts, various ppc TLB flush issues, some possible stack overflows in
networking and a number of other details warranting a quick -rc5 before
the final 2.6.11.
This time it's really supposed to be a quickie, so people who ca
FYI, pci_set_drvdata() needs to be one of the last functions called
during PCI ->probe().
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
David Gibson wrote:
Add descrptions to module parameters in the orinoco driver, and also
add permissions to allow them to be exported in sysfs.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: working-2.6/drivers/net/wireless/orinoco.c
=
Cleanup the various bits of initialization code for PCMCIA / PC-Card
orinoco devices. This includes one important bugfix where we could
fail to take the lock in some circumstances.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: working-2.6/drivers/net/wireless/orinoco_cs.c
==
On Wed, 2005-02-23 at 22:11 -0500, Ron Peterson wrote:
> I would like to better understand ext2/3's performance characteristics.
>
> I'm specifically interested in how ext2/3 will handle a /var/spool/mail
> directory w/ ~6000 mbox format inboxes, handling approx 1GB delivered as
> 75,000 messages
Updates to the WEP configuration code. This adds support for shared
key authentication on Agere firmwares. It also adds support (in some
cases) for changing the WEP keys without disabling the MAC port (thus
triggering a reassociation by the firmware). This is needed by 802.1x
implementations, al
john cooper wrote:
Ingo,
We've had a PPC port of your RT work underway with
a focus on trace instrumentation. This is based upon
realtime-preempt-2.6.11-rc2-V0.7.37-02. A diff is
attached.
To the extent possible the tracing facilities are the
same as your x86 work. In the process a few PPC/g
Update firmware detection code. This will now reliably detect
Intersil firmwares past verison 1.x, a serious flaw in the previous
code. It cleans up the code, and reduces the size of the private
structure by using single bits for the various firmware feature flags.
Signed-off-by: David Gibson <[
Delay netif_wake_queue() until the packet has actually been
transmitted, rather than just when the firmware has copied it into its
internal buffers. This seems to prevent problems on some Intersil
firmware versions (I suspect the problems were caused by the
firmware's buffers filling up).
Signed-
Update the initialization code in the various PCI incarnations of the
orinoco driver. This applies similar initialization and shutdown
cleanups to the orinoco_pci, orinoco_plx and orinoco_tmd drivers. It
also adds COR reset support to the orinoco_plx and orinoco_tmd
drivers, improves PCI power ma
Previous patches have brought the in-kernel orinoco driver roughly to
parity with version 0.14alpha2 from out-of-tree. Update the version
number and changelog accordingly.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: working-2.6/drivers/net/wireless/orinoco.c
==
Make the is_ethersnap() function take a void * rather than a pointer
to the internal header structure. This makes more logical sense and
reduces dependencies between different parts of the code.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: working-2.6/drivers/net/wireless/orinoco.c
===
Remove has_ibss_any flag and never set the CREATEIBSS RID when the
ESSID is empty. Too many firmware break if we do.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: working-2.6/drivers/net/wireless/orinoco.c
===
--- working-2
Introduce a free_orinocodev() function into the orinoco driver, used
by the hardware type/initialization modules to free the device
structure in preference to directly calling free_netdev(). At the
moment free_orinocodev() just calls free_netdev(). Future merges will
make it clean up internal sca
Use mdelay() or ssleep() instead of various silly more complicated
ways of delaying in the orinoco driver.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: working-2.6/drivers/net/wireless/orinoco_pci.c
===
--- working-2.6.orig
Jeff, please apply:
Here's a big stack of patches that make a significant step forward on
the long overdue orinoco driver merge. Still quite a long way to go,
but it's something. This patch stack is againt Linus' vanilla +
Viro's big iomap cleanup patch, as requested.
The first 9 patches make o
Removes the orinoco driver's custom and dodgy "connected" variable
used to track whether or not we're associated with an AP. Replaces it
instead with netif_carrier_ok() settings.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: working-2.6/drivers/net/wireless/orinoco.c
===
On Wed, 23 Feb 2005, Ron Peterson wrote:
I would like to better understand ext2/3's performance characteristics.
I'm specifically interested in how ext2/3 will handle a /var/spool/mail
directory w/ ~6000 mbox format inboxes, handling approx 1GB delivered as
75,000 messages daily. Virtually all acc
On Wednesday 23 February 2005 22:05, Anthony DiSante wrote:
> Dmitry Torokhov wrote:
> > Yes, It usually happens either under high load, when mouse interrupts are
> > significantly delayed. Or sometimes it happen when applications poll
> > battey status and on some boxes it takes pretty long time.
* Roland McGrath ([EMAIL PROTECTED]) wrote:
> > * Roland McGrath ([EMAIL PROTECTED]) wrote:
> > > Indeed, I think your patch does not go far enough. I can read POSIX to
> > > say
> > > that the siginfo_t data must be available when `kill' was used, as well.
> >
> > How? I only see reference to
I would like to better understand ext2/3's performance characteristics.
I'm specifically interested in how ext2/3 will handle a /var/spool/mail
directory w/ ~6000 mbox format inboxes, handling approx 1GB delivered as
75,000 messages daily. Virtually all access is via imap, w/ approx
~1000 imapd p
* Roland McGrath ([EMAIL PROTECTED]) wrote:
> While looking into the issues Jeremy had with the RLIMIT_SIGPENDING limit,
> it occurred to me that the normal setting of this limit is bizarrely low.
> The initial hard limit setting (MAX_SIGPENDING) was taken from the old
> max_queued_signals paramete
Dmitry Torokhov wrote:
Yes, It usually happens either under high load, when mouse interrupts are
significantly delayed. Or sometimes it happen when applications poll
battey status and on some boxes it takes pretty long time. And because
it is usually the same chip that serves keyboard/mouse it agai
* Roland McGrath ([EMAIL PROTECTED]) wrote:
> > Two questions: 1) This changes the interface for consumers of
> > /proc/[pid]/status data, do we care? Adding new line like this should be
> > safe enough.
>
> As far as I can tell, noone fretted about the addition of Threads:,
> ShdPnd:, etc., whic
On Thu, 2005-02-24 at 13:41 +1100, Nick Piggin wrote:
> Lee Revell wrote:
> >
> > Agreed, it would be much better to optimize this away than just add a
> > scheduling point. It seems like we could do this lazily.
> >
>
> Oh? What do you mean by lazy? IMO it is sort of implemented lazily now.
>
On Wed, 23 Feb 2005 14:31:20 -0500, Bill Davidsen <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Hello
> >
> > I have read a post in lkml.org that states that the problem experienced in
> > rc3 has gone (1). That is not the case for me.
> >
> > My audio device is
> >
> > :00:1f.5 Mul
> Does this patch do anything useful?
>
> Jeff
>
Not really. It doesn't print the nobody cared
message, but still hangs at boot. I'd give you a
backtrace but my MAGIC_SYSRQ doesn't seem to be
working right now.
-Brian
Linux version 2.6.11-rc4 ([EMAIL PROTECTED])
(gcc version 3.3.2) #
> Two questions: 1) This changes the interface for consumers of
> /proc/[pid]/status data, do we care? Adding new line like this should be
> safe enough.
As far as I can tell, noone fretted about the addition of Threads:,
ShdPnd:, etc., which were not always there.
> 2) Perhaps we should do /pro
> * Roland McGrath ([EMAIL PROTECTED]) wrote:
> > Indeed, I think your patch does not go far enough. I can read POSIX to say
> > that the siginfo_t data must be available when `kill' was used, as well.
>
> How? I only see reference to filling in SI_USER for rt signals?
> Just curious...(I've onl
Lee Revell wrote:
On Thu, 2005-02-24 at 12:29 +1100, Nick Piggin wrote:
Lee Revell wrote:
IIRC last time I really tested this a few months ago, the worst case
latency on that machine was about 150us. Currently its 422us from the
same clear_page_range code path.
Well it should be pretty trivial to
"Chad N. Tindel" <[EMAIL PROTECTED]> wrote:
>
> We have hit a defect where an exiting xterm process will hang. This is
> running
> on a 2-cpu IA-64 box. We have a multithreaded application, where one thread
> is SCHED_FIFO and is running with priority 98, and the other thread is just
> a nor
BTW, please CC your replies to linux-ide@vger.kernel.org as well.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkm
Does this patch do anything useful?
Jeff
= drivers/scsi/sata_sil.c 1.44 vs edited =
--- 1.44/drivers/scsi/sata_sil.c2005-02-17 19:43:51 -05:00
+++ edited/drivers/scsi/sata_sil.c 2005-02-23 21:27:18 -05:00
@@ -65,6 +65,7 @@
static u32 sil_scr_read (struct ata_port *ap,
* Roland McGrath ([EMAIL PROTECTED]) wrote:
> Jeremy mentioned the aggravation of not being able to tell when your
> processes are using up signal queue entries and hitting the
> RLIMIT_SIGPENDING limit. This patch adds a line to /proc/PID/status
> showing how many queue items are in use, and allo
* Roland McGrath ([EMAIL PROTECTED]) wrote:
> Indeed, I think your patch does not go far enough. I can read POSIX to say
> that the siginfo_t data must be available when `kill' was used, as well.
How? I only see reference to filling in SI_USER for rt signals?
Just curious...(I've only got SuSv3
On Thu, 2005-02-24 at 12:29 +1100, Nick Piggin wrote:
> Lee Revell wrote:
> >
> > IIRC last time I really tested this a few months ago, the worst case
> > latency on that machine was about 150us. Currently its 422us from the
> > same clear_page_range code path.
> >
> Well it should be pretty tri
While looking into the issues Jeremy had with the RLIMIT_SIGPENDING limit,
it occurred to me that the normal setting of this limit is bizarrely low.
The initial hard limit setting (MAX_SIGPENDING) was taken from the old
max_queued_signals parameter, which was for the entire system in aggregate.
But
On Tuesday 22 February 2005 04:57 am, Martin MOKREJŠ wrote:
> The 3GB labeled file corresponds to fast case, 4GB is ugly slow.
> What can you gather from those files?
I did take a look and didn't analyze it further since Andi Mentioned it is a
known BIOS bug.
Sorry about the trouble - didn't imagi
On Thu, Feb 24, 2005 at 03:03:33AM +0100, Benoit Boissinot wrote:
> On Wed, 23 Feb 2005 16:41:59 -0800, Matt Mackall <[EMAIL PROTECTED]> wrote:
> > On Wed, Feb 23, 2005 at 04:16:53PM -0800, Andrew Morton wrote:
> > > Steven Cole <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > Yes, that worked. 2.6.11
Jay wrote:
> I think the microbenchmarking your link provides is irrelevant.
In the cases such as you describe where it's just some sort of empty
function call, then yes, I am willing to accept a wave of the hands and
a simple explanation of how it's not significant. I've done the same
myself ;).
Jeremy mentioned the aggravation of not being able to tell when your
processes are using up signal queue entries and hitting the
RLIMIT_SIGPENDING limit. This patch adds a line to /proc/PID/status
showing how many queue items are in use, and allowed, for your uid.
I can certainly see the appeal o
> -Memory: 255872k available (1788k kernel code, 976k data, 144k init, 0k
> highmem)
> +Memory: 255872k available (1776k kernel code, 0k data, 144k init, 0k highmem)
That is weird... (0k data)
> AGP special page: 0xc000
> Calibrating delay loop... 830.66 BogoMIPS (lpj=4153344)
> Mount-cach
On Wed, 23 Feb 2005, linux-os wrote:
> On Wed, 23 Feb 2005, Bodo Eggert wrote:
> > linux-os <[EMAIL PROTECTED]> wrote:
> >> You don't seem to understand. A process that's stuck in 'D' state
> >> shows a SEVERE error, usually with a hardware driver.
> >
> > Or a network filesystem mount to a no lon
On Wed, 23 Feb 2005 16:41:59 -0800, Matt Mackall <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 23, 2005 at 04:16:53PM -0800, Andrew Morton wrote:
> > Steven Cole <[EMAIL PROTECTED]> wrote:
> > >
> > > > Yes, that worked. 2.6.11-rc4-mm1 now boots OK, but hdb1 seems to be
> > > > missing.
> >
> > Looking
Retry... that patch got screwed up in the last
email...
-Brian
__
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail--- libata-core.c.orig 2005-02-23 17:41:03.831836464 -0800
+++ libata-core
I see this problem with the sata_sil.c driver and
SII3112 card. Others have reported seeing a similar
problem: http://lkml.org/lkml/2005/2/6/41
There seems to be a pending interrupt from the drive,
but the code has already set the NIEN bit, so the
ATA_IRQ_TRAP macro doesn't help (the ata_interru
Hi Paul,
I think the microbenchmarking your link provides is irrelevant.
Your link provides benchmarking of doing a fork.
However, we are talking about inserting a callback routine
in a fork and/or an exit. The overhead is a function
call and time spent in the routine. The callback routine
can be c
Indeed, I think your patch does not go far enough. I can read POSIX to say
that the siginfo_t data must be available when `kill' was used, as well.
This patch makes it allocate the siginfo_t, even when that exceeds
{RLIMIT_SIGPENDING}, for any non-RT signal (< SIGRTMIN) not sent by
sigqueue (actua
I run installed and updated sarge. I downloaded 2.6.10 from kernel.org.
When I use apt-get under 2.4.27 everything is OK
When I use apt-get under 2.6.10, I get a segfault
I run the same combination (allthough a different configuration on a Pentium III (Coppermine) and
on a Intel(R) Pentium(R) M p
Lee Revell wrote:
On Thu, 2005-02-24 at 10:27 +1100, Nick Piggin wrote:
If you are using i386 with 2-level page tables (no highmem), then
the behaviour should be more or less identical. Odd.
IIRC last time I really tested this a few months ago, the worst case
latency on that machine was about 15
1 - 100 of 319 matches
Mail list logo
