On Sun, 2007-03-11 at 13:10 +0100, Ingo Molnar wrote:
* Mike Galbraith [EMAIL PROTECTED] wrote:
Full patch for 2.6.21-rc3-mm2:
http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-mm2-rsdl-0.29.patch
I'm seeing a cpu distribution problem running this on my P4 box.
With
On Monday 12 March 2007 18:22, Mike Galbraith wrote:
On Sun, 2007-03-11 at 13:10 +0100, Ingo Molnar wrote:
* Mike Galbraith [EMAIL PROTECTED] wrote:
Full patch for 2.6.21-rc3-mm2:
http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-mm2-rsdl-
0.29.patch
I'm seeing a cpu
Michael K. Edwards [EMAIL PROTECTED] wrote:
On 3/8/07, Eric Dumazet [EMAIL PROTECTED] wrote:
Absolutely not. We dont want to slow down kernel 'just in case a fool might
want to do crazy things'
Actually, I think it would make the kernel (negligibly) faster to bump
f_pos before the
Hi!
I personally think we should do the opposite, add
kthread_should_stop_check_freeze()
or something. kthread_should_stop() is like signal_pending(), we can use
it under spin_lock (and it is probably used this way by some out-of-tree
driver). The new helper is obviously
I have to admit that I don't see the point here - I can't seem to make any
sense of the OR... Jan
Rusty Russell [EMAIL PROTECTED] 12.03.07 00:28
BUILD_BUG_ON_ZERO is named perfectly wrong, and BUILD_BUG_ON_RETURN_ZERO
is too long. Flip three bits, and the name is much more suitable.
[snip]
We need to decide whether we want to do per-container memory
limitation via these data structures, or whether we do it via
a physical scan of some software zone, possibly based on Mel's
patches.
why not do simple page accounting (as done currently
in Linux) and use that for the
On Monday 12 March 2007 18:48, Con Kolivas wrote:
On Monday 12 March 2007 18:22, Mike Galbraith wrote:
On Sun, 2007-03-11 at 13:10 +0100, Ingo Molnar wrote:
* Mike Galbraith [EMAIL PROTECTED] wrote:
Full patch for 2.6.21-rc3-mm2:
On Mar 12 2007 08:23, Jan Beulich wrote:
I have to admit that I don't see the point here - I can't seem to make any
sense of the OR... Jan
BUILD_BUG_OR_ZERO will either (a) result in a build bug or (b) the number
zero, suitable for arithmetic.
Rusty Russell [EMAIL PROTECTED] 12.03.07 00:28
On Mon, 2007-03-12 at 18:48 +1100, Con Kolivas wrote:
Just a couple of questions;
The X/Gforce case; do they alternate cpu between them? By that I mean when
they're the only thing running does the cpu load summate to 1 or does it
summate to 2?
They're each on their own cpu (sibling).
Am Samstag, 10. März 2007 20:19 schrieb Alan Stern:
On Fri, 9 Mar 2007, Oliver Neukum wrote:
Am Freitag, 9. März 2007 21:08 schrieb Alan Stern:
After some more thought, I basically agree with what Oliver wrote
originally. sysfs_dirent is indeed the logical place to store the kref
2.6.19 is ok, 2.6.20.[12] hangs from the moment DMA is turned on (hdparm
-d 1 /dev/hda):
hda: dma_timer_expiry: dma status == 0x20
hda: DMA timeout retry
hda: timeout waiting for DMA
hda: status error: status=0x58 {
DriveReady
SeekComplete
On Mon, 2007-03-12 at 19:29 +1100, Con Kolivas wrote:
I'll save you the trouble. I just checked myself and indeed the load is only
1. What this means is that although there are 2 tasks running, only one is
running at any time making a total load of 1. So, if we add two other tasks
that add
Maybe you have some ideas how we can decide on this?
We need to work out what the requirements are before we can
settle on an implementation.
Linux-VServer (and probably OpenVZ):
- shared mappings of 'shared' files (binaries
and libraries) to allow for reduced memory
footprint
On Sun, Mar 11, 2007 at 10:26:52PM +0100, Giuliano Pochini wrote:
Since 2.6.20 /sys/devices/system/cpu/cpuX/online isn't there anymore. The
directories exist, though. I also tested linux-2.6.21rc3. I had a look at the
archives and I found nothing about the removal of that file, which is
Hi!
Replace direct invocations of SetPageNosave(), SetPageNosaveFree() etc. with
calls to inline functions that can be changed in subsequent patches without
modifying the code calling them.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
ACK.
Hi!
Make swsusp use memory bitmaps instead of page flags for marking 'nosave' and
free pages. This allows us to 'recycle' two page flags that can be used for
other
purposes. Also, the memory needed to store the bitmaps is allocated when
necessary (ie. before the suspend) and freed after
On Sun 2007-03-11 11:34:53, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
Remove the two page flags that were previously used by swsusp and are no
longer
needed.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
ACK.
Hi,
On 3/9/07, Jim van Wel [EMAIL PROTECTED] wrote:
Hi there,
Please try first a newer kernel of FC6.
2.6.19-1.2911.6.5.fc6
That's 2.6.19.7.
That's the newest one.
I updated my kernel to 2.6.19-1.2911.6.5.fc6 and unfortunately it
doesn't help, I still have these errors.
I attached the
Jiri Kosina napsal(a):
On Sun, 11 Mar 2007, Jiri Slaby wrote:
- /* make sure the unused bits in the last byte are zeros */
- if (count 0 size 0)
- data[(offset+count*size-1)/8] = 0;
-
No, this doesn't help -- -rc3-mm2 minus this behaves exactly the same.
[...]
Dmitriy Monakhov [EMAIL PROTECTED] writes:
- ext3_dx_find_entry() exit with out setting proper error pointer
- do_split() exit with out setting proper error pointer
it is realy painful because many callers contain folowing code:
de = do_split(handle,dir, bh, frame, hinfo,
On Sun, Mar 11, 2007 at 09:20:02AM +0100, Ingo Molnar wrote:
* Pavel Machek [EMAIL PROTECTED] wrote:
Unfortunately, these tend to crash the box when you pass wrong
options, and I do not see easy way to test can user see whats on
display automatically.
you could perhaps try what X's
On 3/12/07, Francis Moreau [EMAIL PROTECTED] wrote:
I updated my kernel to 2.6.19-1.2911.6.5.fc6 and unfortunately it
doesn't help, I still have these errors.
I attached the new dmesg, if anybody can give me some hints that would be great.
oops sent it too fast...
with the dmesg this time.
Subject: [patch] futex: PI state locking fix
From: Ingo Molnar [EMAIL PROTECTED]
testing of -rt by IBM uncovered a locking bug in wake_futex_pi(): the PI
state needs to be locked before we access it.
this patch has been tested in -rt. Must-have for v2.6.21.
Signed-off-by: Ingo Molnar [EMAIL
On Monday 12 March 2007 19:55, Mike Galbraith wrote:
On Mon, 2007-03-12 at 19:29 +1100, Con Kolivas wrote:
I'll save you the trouble. I just checked myself and indeed the load is
only 1. What this means is that although there are 2 tasks running, only
one is running at any time making a
On Mon, 2007-03-12 at 08:23 +, Jan Beulich wrote:
I have to admit that I don't see the point here - I can't seem to make
any sense of the OR... Jan
At least one other person thought that:
#define BUILD_BUG_ON_ZERO(e) BUILD_BUG_ON((e) == 0)
OTOH, BUILD_BUG_OR_ZERO says what
On Thursday 08 March 2007 10:19, Chris Friesen wrote:
I still haven't seen any replies, so I'm resending with a few more
people directly in the TO list.
The timeslice of a SCHED_RR process currently varies with nice level the
same way that it does for SCHED_OTHER. I've included a small app
On Mon, 2007-03-12 at 20:22 +1100, Con Kolivas wrote:
On Monday 12 March 2007 19:55, Mike Galbraith wrote:
On Mon, 2007-03-12 at 19:29 +1100, Con Kolivas wrote:
I'll save you the trouble. I just checked myself and indeed the load is
only 1. What this means is that although there are 2
On Mon, Mar 12, 2007 at 10:28:13AM +1100, Rusty Russell wrote:
BUILD_BUG_ON_ZERO is named perfectly wrong, and BUILD_BUG_ON_RETURN_ZERO
is too long. Flip three bits, and the name is much more suitable.
Ok for me.
-Andi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
Hi!
Quoting Linus Torvalds [EMAIL PROTECTED]:
Ok, it does indeed solve the problem for me.
Not yet for me unfortunately, although this seems to help.
Is this the patch I should have applied?
http://lkml.org/lkml/2007/3/5/445
With this applied, on resume I get
On Sun, Mar 11, 2007 at 05:25:46PM -0700, Jeremy Fitzhardinge wrote:
Andi Kleen wrote:
Hmm, it probably needs a EXPORT_SYMBOL. The previous change only
fixed the in kernel build.
Does it work with this patch?
-Andi
Export _proxy_pda for gcc 4.2
Gak. It seemed like such a
doesn't look so good for me, mainly becaus of the
additional per page data and per page processing
on 4GB memory, with 100 guests, 50% shared for each
guest, this basically means ~1mio pages, 500k shared
and 1500k x sizeof(page_container) entries, which
roughly boils down to ~25MB of wasted
On Mon, 2007-03-12 at 20:22 +1100, Con Kolivas wrote:
On Monday 12 March 2007 19:55, Mike Galbraith wrote:
Hmm. So... anything that's client/server is going to suffer horribly
unless niced tasks are niced all the way down to 19?
Fortunately most client server models dont usually have
On Monday 12 March 2007, Gene Heskett wrote:
On Monday 12 March 2007, Con Kolivas wrote:
Hi Gene.
On Monday 12 March 2007 16:38, Gene Heskett wrote:
I hate to say it Con, but this one seems to have broken the
amanda-tar symbiosis.
I haven't tried a plain 21-rc3, so the problem may exist
On Monday 12 March 2007 20:38, Mike Galbraith wrote:
On Mon, 2007-03-12 at 20:22 +1100, Con Kolivas wrote:
On Monday 12 March 2007 19:55, Mike Galbraith wrote:
On Mon, 2007-03-12 at 19:29 +1100, Con Kolivas wrote:
I'll save you the trouble. I just checked myself and indeed the load
Troy Benjegerdes [EMAIL PROTECTED] writes:
I am attempting to make a 2.6.20 kernel boot on a Cray XD1 node with a
Mellanox InfiniBand card installed, however both the ancient supplied
cray 2.6.5 suse derivative, and a 2.6.20 kernel I just booted fail
on APIC initialization.
Below is a diff
On Monday 12 March 2007 20:38, Xavier Bestel wrote:
On Mon, 2007-03-12 at 20:22 +1100, Con Kolivas wrote:
On Monday 12 March 2007 19:55, Mike Galbraith wrote:
Hmm. So... anything that's client/server is going to suffer horribly
unless niced tasks are niced all the way down to 19?
Sorry for last post, i have been sent to the wrong mailing list.
I was looking for ltsp list and did not notice that OpenSuscriber
had changed the group. Thousand excuses!
--
This message was sent on behalf of [EMAIL PROTECTED] at openSubscriber.com
Hello.
I am new to the LTSP local devices, even though my TS works fine. The
need to use local storage (read USB keys) prompted me to install the
local storage part. I am running a 32bit debian etch and followed the
ltsp4.2:
http://wiki.ltsp.org/twiki/bin/view/Ltsp/LTSP-42-LocalDev-DebianEtch
and
Hello Vincent,
patched kernel. Now it looks more like 5 seconds faster!
Wow.. nice work CK!
2.6.18.8 vanilla kernel:
[ 48.185716] libata version 2.00 loaded.
[ 49.838513] scsi0 : sata_nv
2.6.18.8-rsdl-0.30:
[ 43.144312] libata version 2.00 loaded.
[ 45.820504] Vendor:
Hi Amit,
On Thu, Mar 08, 2007 at 11:14:01PM -0800, Amit Choudhary wrote:
Description: Check the return value of kmalloc() in function
videocodec_build_table(), in file drivers/media/video/videocodec.c.
No need for `Description:'. This line is automatically put in the logs
as a patch
On Mon, 2007-03-12 at 10:13 +0100, Ingo Molnar wrote:
Subject: [patch] futex: PI state locking fix
From: Ingo Molnar [EMAIL PROTECTED]
testing of -rt by IBM uncovered a locking bug in wake_futex_pi(): the PI
state needs to be locked before we access it.
this patch has been tested in -rt.
Davide,
On Sun, 2007-03-11 at 16:04 -0700, Davide Libenzi wrote:
+static int timerfd_setup(struct timerfd_ctx *ctx, int clockid, int tmrtype,
+ const struct itimerspec *ktmr)
+{
+ enum hrtimer_mode htmode;
+ ktime_t texp, tintv;
+
+ if (clockid !=
On Mon, 2007-03-12 at 21:27 +1100, Con Kolivas wrote:
On Monday 12 March 2007 20:38, Mike Galbraith wrote:
Now I think you're getting carried away because of your expectations from the
previous scheduler and its woefully unfair treatment towards interactive
tasks. Look at how you're
Soeren Sonnenburg wrote:
Elsewise I still see the
ATA: abnormal status 0x80 on port 0x000140df
ATA: abnormal status 0x80 on port 0x000140df
ata1.00: configured for UDMA/33
ata3.01: revalidation failed (errno=-2)
ata3: failed to recover some devices, retrying in 5 secs
ATA: abnormal status
At Sat, 10 Mar 2007 19:05:13 +,
Ralf Baechle wrote:
CC [M] sound/pci/hda/hda_intel.o
sound/pci/hda/hda_intel.c:1508: error: position_fix_list causes a section
type conflict
Gcc like its __devinitdata readable not const, it seems. An alternative
fix would be to remove the
* Mike Galbraith [EMAIL PROTECTED] wrote:
The test scenario was one any desktop user might do with every
expectation responsiveness of the interactive application remain
intact. I understand the concepts here Con, and I'm not knocking your
scheduler. I find it to be a step forward on the
Hi folks.
I have a simple program, that analyzes ethernet packets. Counting
traffic on from/to basis, and dumping that informatio nevery minute.
Everything is cleared - in terms of memory, valgrind doesn't complain
a bit.
But once every 2-3 days the router on which the software is running,
Hi
I am trying to boot 2.6.20.2 on a Gigabyte GA-M57SLI-S4 with f7 stock bios.
I get the message:
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=0 apic2=-1 pin2=-1
..MP-BIOS bug: 8254 timer not connected to IO-APIC
...trying to set up timer (IRQ0) through the 8259A ... failed.
...trying
At Sat, 10 Mar 2007 00:31:33 -0500,
Dave Jones wrote:
=
[ INFO: possible recursive locking detected ]
2.6.20-1.2962.fc7 #1
-
rosegardenseque/5229 is trying to acquire lock:
(grp-list_mutex){}, at:
On Monday 12 March 2007, Radoslaw Szkodzinski wrote:
On 3/11/07, Gene Heskett [EMAIL PROTECTED] wrote:
On Sunday 11 March 2007, Mike Galbraith wrote:
Just to comment, I've been running one of the patches between 20-ck1
and this latest one, which is building as I type, but I also run
gkrellm
Hi,
On Monday, 12 March 2007 09:14, Pavel Machek wrote:
Hi!
I personally think we should do the opposite, add
kthread_should_stop_check_freeze()
or something. kthread_should_stop() is like signal_pending(), we can use
it under spin_lock (and it is probably used this way by
On Sunday, 11 March 2007 21:45, Soeren Sonnenburg wrote:
(sorry if I am CC'ing the wrong people, seemed for me this is related to
rc-2 regression 5/6)
After a very long compile sessions (is there something like git bisect
to speed this up?) to find the config options that break s2ram between
Con Kolivas wrote:
On Monday 12 March 2007 15:42, Al Boldi wrote:
Con Kolivas wrote:
On Monday 12 March 2007 08:52, Con Kolivas wrote:
And thank you! I think I know what's going on now. I think each
rotation is followed by another rotation before the higher priority
task is
On Monday 12 March 2007 22:08, Ingo Molnar wrote:
* Mike Galbraith [EMAIL PROTECTED] wrote:
The test scenario was one any desktop user might do with every
expectation responsiveness of the interactive application remain
intact. I understand the concepts here Con, and I'm not knocking your
On Mon, Mar 12, 2007 at 09:54:47AM +0100, Frank van Maarseveen wrote:
2.6.19 is ok, 2.6.20.[12] hangs from the moment DMA is turned on (hdparm
-d 1 /dev/hda):
hda: dma_timer_expiry: dma status == 0x20
hda: DMA timeout retry
hda: timeout waiting for DMA
hda: status
On Mon, 2007-03-12 at 12:08 +0100, Ingo Molnar wrote:
* Mike Galbraith [EMAIL PROTECTED] wrote:
The test scenario was one any desktop user might do with every
expectation responsiveness of the interactive application remain
intact. I understand the concepts here Con, and I'm not
Rusty Russell wrote:
On Mon, 2007-03-12 at 08:23 +, Jan Beulich wrote:
I have to admit that I don't see the point here - I can't seem to make
any sense of the OR... Jan
At least one other person thought that:
#define BUILD_BUG_ON_ZERO(e) BUILD_BUG_ON((e) == 0)
OTOH,
On Monday 12 March 2007, Gene Heskett wrote:
On Monday 12 March 2007, Radoslaw Szkodzinski wrote:
On 3/11/07, Gene Heskett [EMAIL PROTECTED] wrote:
On Sunday 11 March 2007, Mike Galbraith wrote:
Just to comment, I've been running one of the patches between 20-ck1
and this latest one, which is
On Mon, 12 Mar 2007, Stefan Richter wrote:
Rusty Russell wrote:
On Mon, 2007-03-12 at 08:23 +, Jan Beulich wrote:
I have to admit that I don't see the point here - I can't seem to make
any sense of the OR... Jan
At least one other person thought that:
#define
On 12/03/07, Gene Heskett [EMAIL PROTECTED] wrote:
On Monday 12 March 2007, Gene Heskett wrote:
To Con, I knew 2.6.20 worked with your earlier patches, so rather than
revert all the way, I just rebooted to 2.6.20.2-rdsl-0.30 and I'm going
to fire off another backup. I suspect it will work, but
On Monday 12 March 2007 11:24, Frank van Maarseveen wrote:
On Mon, Mar 12, 2007 at 09:54:47AM +0100, Frank van Maarseveen wrote:
2.6.19 is ok, 2.6.20.[12] hangs from the moment DMA is turned on (hdparm
-d 1 /dev/hda):
hda: dma_timer_expiry: dma status == 0x20
hda: DMA timeout
Hi,
Could you check if this is the same problem as this one:
http://bugzilla.kernel.org/show_bug.cgi?id=8169
Thanks,
Bart
On Monday 12 March 2007, Frank van Maarseveen wrote:
On Mon, Mar 12, 2007 at 09:54:47AM +0100, Frank van Maarseveen wrote:
2.6.19 is ok, 2.6.20.[12] hangs from the
* Roland McGrath [EMAIL PROTECTED] wrote:
I agree it should restart. But I don't think this is quite right in
the timeout case. It will increase the total maximum real time spent
arbitrarily by the amount of time elapsed in signal handlers. Other
restartable, timed calls have to
On Mon, Mar 12, 2007 at 10:10:06AM +0100, Ingo Molnar wrote:
* Roland McGrath [EMAIL PROTECTED] wrote:
I agree it should restart. But I don't think this is quite right in
the timeout case. It will increase the total maximum real time spent
arbitrarily by the amount of time elapsed
Krzysztof Halasa wrote:
Tosoni [EMAIL PROTECTED] writes:
As far as I know in the old times this was the *standard*
way to use a modem
(per CCITT V24), and even nowadays many modems can handle
this method for
transmit, to stay compatible with the standard.
I think it wasn't standard for
Ingo Molnar [EMAIL PROTECTED] writes:
the only correct approach is the use of hrtimers, and a patch exists for
that - see below. This has been included in -rt for quite some time.
But isn't that bad for power management? You'll likely get more
idle wakeups, won't you?
-Andi
-
To
On Mon, 2007-03-12 at 12:27 +0100, Andi Kleen wrote:
Ingo Molnar [EMAIL PROTECTED] writes:
the only correct approach is the use of hrtimers, and a patch exists for
that - see below. This has been included in -rt for quite some time.
But isn't that bad for power management? You'll
On Mon, Mar 12, 2007 at 12:00:20PM +0100, Thomas Gleixner wrote:
On Mon, 2007-03-12 at 12:27 +0100, Andi Kleen wrote:
Ingo Molnar [EMAIL PROTECTED] writes:
the only correct approach is the use of hrtimers, and a patch exists for
that - see below. This has been included in -rt for
* Nick Piggin [EMAIL PROTECTED] wrote:
i dont think we should try to do this. We should not and cannot do
anything about all of the artifacts that comes with the use of
relative timeouts and schedule_timeout().
basically, using jiffies here (which schedule_timeout() does) is
* Andi Kleen [EMAIL PROTECTED] wrote:
On Mon, Mar 12, 2007 at 12:00:20PM +0100, Thomas Gleixner wrote:
On Mon, 2007-03-12 at 12:27 +0100, Andi Kleen wrote:
Ingo Molnar [EMAIL PROTECTED] writes:
the only correct approach is the use of hrtimers, and a patch exists
for
that
On Sun, 11 Mar 2007, David Miller wrote:
I'm going to make the radical declaration that it be perhaps often
better to always initialize page table chunks to all zeros on
allocation.
That is the case if most of the page is going to be used soon. If we have
sparse access patterns then not
On Mon, 2007-03-12 at 12:02 +0100, Ingo Molnar wrote:
Well I did convert futex_wait to an absolute timeout based version in
the subsequent incremental patch. I think that is OK?
it still has the rounding artifacts: using timer_list there is no way to
do a precise long sleep based on many
On Mon, Mar 12, 2007 at 12:02:04PM +0100, Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:
i dont think we should try to do this. We should not and cannot do
anything about all of the artifacts that comes with the use of
relative timeouts and schedule_timeout().
* Nick Piggin [EMAIL PROTECTED] wrote:
even if this means more work for you (i'm sorry about that!) i'm
quite sure we should take Sebastien's hrtimers based implementation
of futex_wait(), and use the nanosleep method to restart it. There's
no point in further tweaking the imprecise
if HIGH_RES_TIMERS is disabled then that is what happens. But frankly,
disabled? I would expect it (= more wakeups) when hrtimers are enabled.
most futex waits are without timeouts - if an application cares about
micro-effects like that then you are much better off not using a
per-futex
From: Christoph Lameter [EMAIL PROTECTED]
Date: Mon, 12 Mar 2007 04:12:32 -0700 (PDT)
On Sun, 11 Mar 2007, David Miller wrote:
I'm going to make the radical declaration that it be perhaps often
better to always initialize page table chunks to all zeros on
allocation.
That is the case
* Andi Kleen [EMAIL PROTECTED] wrote:
if HIGH_RES_TIMERS is disabled then that is what happens. But
frankly,
disabled? I would expect it (= more wakeups) when hrtimers are
enabled.
i mean the groupping of timer expiries happens automatically when
high-res is disabled. When high-res
On Mon, Mar 12, 2007 at 12:19:58PM +0100, Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:
even if this means more work for you (i'm sorry about that!) i'm
quite sure we should take Sebastien's hrtimers based implementation
of futex_wait(), and use the nanosleep method to
* Nick Piggin [EMAIL PROTECTED] wrote:
the issue is this: your fix reduces the effects of the bug but it is
still fundamentally incomplete because of the use of timer_list. So
But using schedule_timeout is not a bug. Userspace timeouts are always
defined to be at least.
but what you
I have no idea how serious the scalability problems with this are. If
they are serious, different solutions can probably be found for the
above, but this is certainly the simplest.
Atomic operations to a single per-backing device from all CPUs at once?
That's a pretty serious
On Mon, Mar 12, 2007 at 12:38:29PM +0100, Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:
the issue is this: your fix reduces the effects of the bug but it is
still fundamentally incomplete because of the use of timer_list. So
But using schedule_timeout is not a bug.
I realy don't want to be annoying by sending this patcheset over and over
again. If anyone think this patch is realy cappy, please comment what
exectly is bad. Thank you.
Changes:
- patch was split in two patches.
- comments added. I think now it is clearly describe things.
- make
I realy don't want to be annoying by sending this patcheset over and over
again, i just want the issue to be solved. If anyone think this solution
is realy cappy, please comment what exectly is bad. Thank you.
Changes:
- patch was split in two patches.
- comments added. I think now it is
On Mon, Mar 12, 2007 at 10:58:10AM +0300, Dmitriy Monakhov wrote:
I realy don't want to be annoying by sending this patcheset over and over
again, i just want the issue to be solved. If anyone think this solution
is realy cappy, please comment what exectly is bad. Thank you.
If you don't get
On Mon, Mar 12, 2007 at 10:57:53AM +0300, Dmitriy Monakhov wrote:
+/*
+ * Performs necessary checks before doing a write
+ *
+ * Adjust number of segments and amount of bytes to write.
+ * Returns appropriate error code that caller should return or
+ * zero in case that write should be
On Mon, Mar 12, 2007 at 10:57:53AM +0300, Dmitriy Monakhov wrote:
I realy don't want to be annoying by sending this patcheset over and over
again. If anyone think this patch is realy cappy, please comment what
exectly is bad. Thank you.
Doesn't seem like a bad idea.
Changes:
- patch
Nick Piggin [EMAIL PROTECTED] writes:
On Mon, Mar 12, 2007 at 10:58:10AM +0300, Dmitriy Monakhov wrote:
I realy don't want to be annoying by sending this patcheset over and over
again, i just want the issue to be solved. If anyone think this solution
is realy cappy, please comment what
On Mon, Mar 12, 2007 at 11:55:30AM +0300, Dmitriy Monakhov wrote:
Nick Piggin [EMAIL PROTECTED] writes:
On Mon, Mar 12, 2007 at 10:58:10AM +0300, Dmitriy Monakhov wrote:
@@ -2240,6 +2241,29 @@ ssize_t generic_file_aio_write(struct kiocb *iocb,
const struct iovec *iov,
Eric,
And misses every resource sharing opportunity in sight.
that was my point too.
Except for
filtering the which pages are eligible for reclaim an RSS limit should
not need to change the existing reclaim logic, and with things like the
memory zones we have had that kind of restriction
Nick Piggin [EMAIL PROTECTED] writes:
On Mon, Mar 12, 2007 at 11:55:30AM +0300, Dmitriy Monakhov wrote:
Nick Piggin [EMAIL PROTECTED] writes:
On Mon, Mar 12, 2007 at 10:58:10AM +0300, Dmitriy Monakhov wrote:
@@ -2240,6 +2241,29 @@ ssize_t generic_file_aio_write(struct kiocb *iocb,
On Mon, Mar 12, 2007 at 12:23:00PM +0300, Dmitriy Monakhov wrote:
Nick Piggin [EMAIL PROTECTED] writes:
On Mon, Mar 12, 2007 at 11:55:30AM +0300, Dmitriy Monakhov wrote:
Nick Piggin [EMAIL PROTECTED] writes:
On Mon, Mar 12, 2007 at 10:58:10AM +0300, Dmitriy Monakhov wrote:
@@
Cong WANG wrote:
Use NULL to indicate we are returning a pointer rather than an integer
and to eliminate some sparse warnings.
Signed-off-by: Cong WANG [EMAIL PROTECTED]
These are already fixed in my repo.
--
error compiling committee.c: too many arguments to function
-
To unsubscribe from
On 03/12, Rafael J. Wysocki wrote:
On Monday, 12 March 2007 09:14, Pavel Machek wrote:
Can we get better name for this function?
Well, I took the name from the Oleg's message. Can you please suggest
something?
Well, kthread_should_stop_check_freeze() is really awful, I agree :)
We
On Mon, Mar 12, 2007 at 01:21:18PM +0100, Bartlomiej Zolnierkiewicz wrote:
Hi,
Could you check if this is the same problem as this one:
http://bugzilla.kernel.org/show_bug.cgi?id=8169
Looks like it except that I don't see lost interrupt messages here. So,
it might be something different
Your message dated Mon, 12 Mar 2007 07:37:15 -0500 with subject Message
could not be delivered has been submitted to the moderator of the SPORTS
list: John Hartrick [EMAIL PROTECTED].
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
On Monday 12 March 2007 22:26, Al Boldi wrote:
Con Kolivas wrote:
On Monday 12 March 2007 15:42, Al Boldi wrote:
Con Kolivas wrote:
On Monday 12 March 2007 08:52, Con Kolivas wrote:
And thank you! I think I know what's going on now. I think each
rotation is followed by another
I went from 2.6.18-rc5-mm1 to 2.6.21-rc3-mm2
The computer now hangs solid during boot, at this point:
usb 1-1: configuration #1 chosen from 1 choice
drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 2 if 0
alt 0 proto 2 vid 0x04B8 pid 0x0007
usb 1-3: new high speed USB device
On Fri, Mar 09, 2007 at 08:10:03PM +0200, Avi Kivity wrote:
Joerg Roedel wrote:
From: Joerg Roedel [EMAIL PROTECTED]
This patch simplifies the get_cycles_sync() function by removing
the #ifdefs from it. Further it introduces an optimization for AMD
processors. There the RDTSCP instruction
Andi, have you had a look at this? I'm a bit surprised at the lack of
reaction to this find..
FYI the problem is still being analysed behind the scenes. Chip's patch didn't
fix
it in all cases unfortunately -- it just changed the timing enough to make it
happen
less often. The latest
On Monday 12 March 2007 14:02, Joerg Roedel wrote:
On Fri, Mar 09, 2007 at 08:10:03PM +0200, Avi Kivity wrote:
Joerg Roedel wrote:
From: Joerg Roedel [EMAIL PROTECTED]
This patch simplifies the get_cycles_sync() function by removing
the #ifdefs from it. Further it introduces an
1 - 100 of 980 matches
Mail list logo
