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 obvio
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.
S
[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
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:
> > > > > http://ck.kolivas.org/patches/stair
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
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 k
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
D
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
>>> 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
>
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 aft
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.
[...]
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
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 happe
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 a
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 a
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"
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
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
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 memor
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 hav
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 probl
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 l
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
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
http://www.opensubscriber.com/messages/linux-ker
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
h
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]
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 descrip
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
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 != CLO
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
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
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,
freez
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 t
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){---
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
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 use
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 bet
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
> >
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 knockin
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:
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 no
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 lates
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:
> >
> > #defin
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,
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
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 t
* 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 c
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
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'
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 unsubs
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? Yo
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 i
* 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)
* 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
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 ze
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 o
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 im
> 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-fute
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 i
* 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 hi
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 nanosle
* 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
> > 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 sc
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
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 generic_s
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 clear
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:
> - pat
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 wha
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 restricti
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 kio
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 w
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 fro
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
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 dif
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 P
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 f
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 usi
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 i
> 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 evi
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 intro
>
> Hello Vincent,
>
> As it seems the 5s net gain is during the early phase of the
> boot process, could you please post longer dmesgs, to let us
> know where the gain occurs ?
Hi Paul,
Here is an sdiff between the two dmesg:
[0.00] Linux version 2.6.18.8-amd64-envcan-003 (root@ | [
Gene Heskett <[EMAIL PROTECTED]> writes:
> If, and I have previously, I revert to a 2.6.20-ck1 patching, this does
> not occur. So my contention is that someplace in this recent progression
> from 2.6.20 to 2.6.21-rc3, there is a patch which acts to change how
> c-time is being reported to tar
> > There's a substantial performance hit for not yield, so we probably
> > want to investigate alternate semantics for it. It seems reasonable
> > for apps to say "let me not hog the CPU" without completely expiring
> > them. Imagine you're in the front of the line (aka queue) and you
> > spend a
On Mon, Mar 12, 2007 at 02:09:18PM +0100, Andi Kleen wrote:
> 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_cycle
Oleg Nesterov wrote:
> 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 rea
1 - 100 of 500 matches
Mail list logo
