On 30.11.2012 23:52, Tejun Heo wrote:
Hello, Zlatko.
Sorry about the delay. Your message was in my spam folder. The
attachment seems to have confused the filter.
On Sat, Nov 17, 2012 at 02:01:29PM +0100, Zlatko Calusic wrote:
This week I spent some hours tracking a regression in 3.7 kernel
On 30.11.2012 23:55, Tejun Heo wrote:
> Hello, again.
>
> Can you please try this patch? Thanks!
>
> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> index 042d221..26368ef 100644
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -1477,7 +1477,10 @@ bool mod_delayed_work_on(int cp
On 01.12.2012 15:38, Tejun Heo wrote:
Hello,
On Sat, Dec 01, 2012 at 12:06:41PM +0100, Zlatko Calusic wrote:
I have good news. The patch fixes the regression!
To doublecheck and provide you additional data, I updated to the latest Linus
kernel (commit 7c17e48), recompiled (WITHOUT the patch
On 01.12.2012 20:13, Tejun Heo wrote:
Hello,
On Sat, Dec 01, 2012 at 06:11:10PM +0100, Zlatko Calusic wrote:
Sure. Please clarify, should I apply it on top of the previous one
or standalone?
It's a replacement, so by itself.
Thanks!
I have good news, again. The kernel with the
On 06.12.2012 20:31, Linus Torvalds wrote:
Ok, people seem to be reporting success.
I've applied Johannes' last patch with the new tested-by tags.
I've been testing this patch since it was applied, and it certainly
fixes the kswapd craziness issue, good work Johannes!
But, it's still not p
On 08.12.2012 13:06, Zlatko Calusic wrote:
On 06.12.2012 20:31, Linus Torvalds wrote:
Ok, people seem to be reporting success.
I've applied Johannes' last patch with the new tested-by tags.
I've been testing this patch since it was applied, and it certainly
fixes the kswapd
On 10.12.2012 12:03, Mel Gorman wrote:
There is a big difference between a direct reclaim/compaction for THP
and kswapd doing the same work. Direct reclaim/compaction will try once,
give up quickly and defer requests in the near future to avoid impacting
the system heavily for THP. The same appli
On 10.12.2012 19:01, Mel Gorman wrote:
In this last-minute disaster, I'm not thinking properly at all any more. The
shrink slab disabling should have happened before the loop_again but even
then it's wrong because it's just covering over the problem.
The way order and testorder interact with how
On 10.12.2012 20:13, Linus Torvalds wrote:
>
> It's worth giving this as much testing as is at all possible, but at
> the same time I really don't think I can delay 3.7 any more without
> messing up the holiday season too much. So unless something obvious
> pops up, I will do the release tonight.
On 10.12.2012 22:54, Borislav Petkov wrote:
On Mon, Dec 10, 2012 at 01:47:23PM -0800, Linus Torvalds wrote:
On Mon, Dec 10, 2012 at 1:42 PM, Borislav Petkov wrote:
Aren't we gonna consider the out-of-tree vbox modules being loaded and
causing some corruptions like maybe the single-bit error a
On 11.12.2012 01:19, Zlatko Calusic wrote:
I will now make one last attempt, I've just reverted 2 Johannes' commits
that were also applied in attempt to fix breakage that removing
gfp_no_kswapd introduced, namely ed23ec4 & c702418. For various reasons
the results of this test wil
On 26.12.2012 12:22, Zhouping Liu wrote:
Hello everyone,
The latest mainline(637704cbc95c) would trigger the following error when the
system was under
some pressure condition(in my testing, I used oom01 case inside LTP test suite
to trigger the issue):
[ 5462.920151] BUG: unable to handle ker
ourse.
The patch introduces pgdat_is_balanced boolean, which helps resolve the
above suboptimal behavior, with the added benefit of slightly better
documenting one other place in the function where we jump and skip lots
of code.
Signed-off-by: Zlatko Calusic
Cc: Andrew Morton
Cc: Mel Gorman
Cc:
On 26.12.2012 12:22, Zhouping Liu wrote:
> Hello everyone,
>
> The latest mainline(637704cbc95c) would trigger the following error when the
> system was under
> some pressure condition(in my testing, I used oom01 case inside LTP test
> suite to trigger the issue):
>
> [ 5462.920151] BUG: unable
On 21.12.2012 12:51, Hillf Danton wrote:
On Thu, Dec 20, 2012 at 7:25 AM, Zlatko Calusic wrote:
static unsigned long balance_pgdat(pg_data_t *pgdat, int order,
int *classzone_idx)
{
- int all_zones_ok;
+ struct zone
On 28.12.2012 00:30, Sedat Dilek wrote:
Hi Zlatko,
I am not sure if I hit the same problem as described in this thread.
Under heavy load, while building a customized toolchain for the Freetz
router project I got a BUG || NULL pointer derefence || kswapd ||
zone_balanced || pgdat_balanced() etc.
On 28.12.2012 00:42, Sedat Dilek wrote:
On Fri, Dec 28, 2012 at 12:39 AM, Zlatko Calusic
wrote:
On 28.12.2012 00:30, Sedat Dilek wrote:
Hi Zlatko,
I am not sure if I hit the same problem as described in this thread.
Under heavy load, while building a customized toolchain for the Freetz
On 28.12.2012 00:55, David R. Piegdon wrote:
Hi,
NOTE to everyone debugging this: reproduced quickly with X + firefox +
youtube (adobe flash plugin)
Would you be so kind to test the following patch and report results?
Apply the patch to the latest mainline.
I've had probably the same problem
On 28.12.2012 01:24, Sedat Dilek wrote:
On Fri, Dec 28, 2012 at 12:51 AM, Zlatko Calusic
wrote:
On 28.12.2012 00:42, Sedat Dilek wrote:
On Fri, Dec 28, 2012 at 12:39 AM, Zlatko Calusic
wrote:
On 28.12.2012 00:30, Sedat Dilek wrote:
Hi Zlatko,
I am not sure if I hit the same problem as
On 28.12.2012 01:37, Sedat Dilek wrote:
On Fri, Dec 28, 2012 at 1:33 AM, Zlatko Calusic wrote:
On 28.12.2012 01:24, Sedat Dilek wrote:
On Fri, Dec 28, 2012 at 12:51 AM, Zlatko Calusic
wrote:
On 28.12.2012 00:42, Sedat Dilek wrote:
On Fri, Dec 28, 2012 at 12:39 AM, Zlatko Calusic
wrote
From: Zlatko Calusic
The unintended consequence of commit 4ae0a48b is that
wait_iff_congested() can now be called with NULL struct zone*
producing kernel oops like this:
BUG: unable to handle kernel NULL pointer dereference
IP: [] wait_iff_congested+0x59/0x140
This trivial patch fixes it
On 28.12.2012 03:45, Zhouping Liu wrote:
Thank you for the report Zhouping!
Would you be so kind to test the following patch and report results?
Apply the patch to the latest mainline.
Hello Zlatko,
I have tested the below patch(applied it on mainline directly),
but IMO, I'd like to say it m
On 28.12.2012 03:49, Minchan Kim wrote:
Hello Zlatko,
On Fri, Dec 28, 2012 at 03:16:38AM +0100, Zlatko Calusic wrote:
From: Zlatko Calusic
The unintended consequence of commit 4ae0a48b is that
wait_iff_congested() can now be called with NULL struct zone*
producing kernel oops like this
On 28.12.2012 10:01, Zhouping Liu wrote:
On 12/28/2012 10:45 AM, Zhouping Liu wrote:
Thank you for the report Zhouping!
Would you be so kind to test the following patch and report results?
Apply the patch to the latest mainline.
Hello Zlatko,
I have tested the below patch(applied it on mainli
On 29.12.2012 08:25, Hillf Danton wrote:
On Thu, Dec 27, 2012 at 11:42 PM, Zlatko Calusic
wrote:
On 21.12.2012 12:51, Hillf Danton wrote:
On Thu, Dec 20, 2012 at 7:25 AM, Zlatko Calusic
wrote:
static unsigned long balance_pgdat(pg_data_t *pgdat, int order
On 11.12.2012 01:19, Zlatko Calusic wrote:
On 10.12.2012 20:13, Linus Torvalds wrote:
It's worth giving this as much testing as is at all possible, but at
the same time I really don't think I can delay 3.7 any more without
messing up the holiday season too much. So unless somethi
On a 4GB RAM machine, where Normal zone is much smaller than
DMA32 zone, the Normal zone gets fragmented in time. This requires
relatively more pressure in balance_pgdat to get the zone above the
required watermark. Unfortunately, the congestion_wait() call in there
slows it down for a completely w
d on a machine which
nicely revealed the problem after only 1 day of uptime, and it's been
working great.
Signed-off-by: Zlatko Calusic
---
mm/vmscan.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index b7ed376..4588d1d 100644
-
gdat_balanced() about order-0 allocations so that we can simplify
code in a few places in vmstat.c.
Signed-off-by: Zlatko Calusic
---
mm/vmscan.c | 101 +++-
1 file changed, 45 insertions(+), 56 deletions(-)
diff --git a/mm/vmscan.c b/m
On 22.12.2012 19:54, Zlatko Calusic wrote:
> On 20.12.2012 21:58, Andrew Morton wrote:
>> There seems to be some complexity/duplication here between the new
>> unbalanced_zone() and pgdat_balanced().
>>
>> Can we modify pgdat_balanced() so that it al
Hello Tejun et al.
This week I spent some hours tracking a regression in 3.7 kernel that
was producing high context switch rate on one of my machines. I
carefully bisected between 3.6 and 3.7-rc1 and eventually found this
commit a culprit:
commit e7c2f967445dd2041f0f8e3179cca22bb8bb7f79
Auth
On 12.04.2013 22:07, Zlatko Calusic wrote:
On 12.04.2013 21:40, Mel Gorman wrote:
On Thu, Apr 11, 2013 at 10:55:13PM +0200, Zlatko Calusic wrote:
On 09.04.2013 13:06, Mel Gorman wrote:
- The only slightly negative thing I observed is that with the patch
applied kswapd burns 10x - 20x more
On 22.04.2013 08:43, Simon Jeons wrote:
Hi Zlatko,
On 04/22/2013 02:37 PM, Zlatko Calusic wrote:
On 12.04.2013 22:07, Zlatko Calusic wrote:
On 12.04.2013 21:40, Mel Gorman wrote:
On Thu, Apr 11, 2013 at 10:55:13PM +0200, Zlatko Calusic wrote:
On 09.04.2013 13:06, Mel Gorman wrote:
- The
On 24.07.2013 13:18, Zlatko Calusic wrote:
On 22.07.2013 18:48, Zlatko Calusic wrote:
On 19.07.2013 22:55, Johannes Weiner wrote:
The way the page allocator interacts with kswapd creates aging
imbalances, where the amount of time a userspace page gets in memory
under reclaim pressure is
On 19.07.2013 22:55, Johannes Weiner wrote:
The way the page allocator interacts with kswapd creates aging
imbalances, where the amount of time a userspace page gets in memory
under reclaim pressure is dependent on which zone, which node the
allocator took the page frame from.
#1 fixes missed ks
On 22.07.2013 19:01, Johannes Weiner wrote:
Hi Zlatko,
On Mon, Jul 22, 2013 at 06:48:52PM +0200, Zlatko Calusic wrote:
On 19.07.2013 22:55, Johannes Weiner wrote:
The way the page allocator interacts with kswapd creates aging
imbalances, where the amount of time a userspace page gets in
On 24.07.2013 14:46, Hush Bensen wrote:
δΊ 2013/7/24 19:18, Zlatko Calusic ει:
On 22.07.2013 18:48, Zlatko Calusic wrote:
On 19.07.2013 22:55, Johannes Weiner wrote:
The way the page allocator interacts with kswapd creates aging
imbalances, where the amount of time a userspace page gets in
On 04.03.2013 10:52, Lenky Gao wrote:
Hi,
When i just run a test on Centos 6.2 as follows:
#!/bin/bash
while true
do
file="/tmp/filetest"
echo $file
dd if=/dev/zero of=${file} bs=512 count=204800 &> /dev/null
sleep 5
done
the inactive memory keep growing:
On 09.04.2013 13:06, Mel Gorman wrote:
Posting V2 of this series got delayed due to trying to pin down an unrelated
regression in 3.9-rc where interactive performance is shot to hell. That
problem still has not been identified as it's resisting attempts to be
reproducible by a script for the purp
On 12.04.2013 21:40, Mel Gorman wrote:
On Thu, Apr 11, 2013 at 10:55:13PM +0200, Zlatko Calusic wrote:
On 09.04.2013 13:06, Mel Gorman wrote:
- The only slightly negative thing I observed is that with the patch
applied kswapd burns 10x - 20x more CPU. So instead of about 15
seconds, it has
On 12.04.2013 22:41, Mel Gorman wrote:
On Fri, Apr 12, 2013 at 10:07:54PM +0200, Zlatko Calusic wrote:
On 12.04.2013 21:40, Mel Gorman wrote:
On Thu, Apr 11, 2013 at 10:55:13PM +0200, Zlatko Calusic wrote:
On 09.04.2013 13:06, Mel Gorman wrote:
- The only slightly negative thing I observed
On 15.05.2013 22:37, Andrew Morton wrote:
3.10.0-rc1 3.10.0-rc1
vanilla lessdisrupt-v4
Page Ins 1234608 101892
Page Outs 1244627211810468
Swap Ins283406
On 08.03.2013 07:42, Hillf Danton wrote:
On Fri, Mar 8, 2013 at 3:37 AM, Jiri Slaby wrote:
On 03/01/2013 03:02 PM, Hillf Danton wrote:
On Fri, Mar 1, 2013 at 1:02 AM, Jiri Slaby wrote:
Ok, no difference, kswap is still crazy. I'm attaching the output of
"grep -vw '0' /proc/vmstat" if you se
On 11.01.2013 02:25, Simon Jeons wrote:
> On Wed, 2013-01-09 at 22:41 +0100, Zlatko Calusic wrote:
>> From: Zlatko Calusic
>>
>> Currently we take a short nap (HZ/10) and wait for congestion to clear
>> before taking another pass with lower priority in balance_pgdat().
On 12.01.2013 00:48, a...@linux-foundation.org wrote:
A git tree which contains the memory management portion of this tree is
maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
by Michal Hocko. It contains the patches which are between the
The last commit I see in this t
On 13.01.2013 01:46, Simon Jeons wrote:
> On Fri, 2013-01-11 at 12:25 +0100, Zlatko Calusic wrote:
>> On 11.01.2013 02:25, Simon Jeons wrote:
>>> On Wed, 2013-01-09 at 22:41 +0100, Zlatko Calusic wrote:
>>>> From: Zlatko Calusic
>>>>
>>>&
From: Zlatko Calusic
Commit 92df3a72 (mm: vmscan: throttle reclaim if encountering too many
dirty pages under writeback) introduced waiting on congested zones
based on a sane algorithm in shrink_inactive_list(). What this means
is that there's no more need for throttling and addit
Reported-by: Andrew Clayton
Reported-by: Zlatko Calusic
Tested-by: Andrew Clayton
Signed-off-by: Jiri Kosina
Reported-and-tested-by: Zlatko Calusic
kvm starts just fine now. Thanks Jiri!
--
Zlatko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On 19.01.2013 00:49, a...@linux-foundation.org wrote:
The mm-of-the-moment snapshot 2013-01-18-15-48 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
WARNING: vmlinux.o(.text+0x43f025): Section mismatch in reference from
the function release_firmware_map_entry() to the function
.
From: Zlatko Calusic
Currently we take a short nap (HZ/10) and wait for congestion to clear
before taking another pass with lower priority in balance_pgdat(). But
we do that only for the highest zone that we encounter is unbalanced
and congested.
This patch changes that to wait on all congested
On 09.01.2013 22:48, Andrew Morton wrote:
On Wed, 09 Jan 2013 22:41:48 +0100
Zlatko Calusic wrote:
Currently we take a short nap (HZ/10) and wait for congestion to clear
before taking another pass with lower priority in balance_pgdat(). But
we do that only for the highest zone that we
On 09.01.2013 22:48, Andrew Morton wrote:
On Wed, 09 Jan 2013 22:41:48 +0100
Zlatko Calusic wrote:
Currently we take a short nap (HZ/10) and wait for congestion to clear
before taking another pass with lower priority in balance_pgdat(). But
we do that only for the highest zone that we
The following patch cleans up some obsolete structures from the mm &
proc code.
Beside that it also fixes what I think is a bug:
if ((rw == WRITE) && atomic_read(&nr_async_pages) >
pager_daemon.swap_cluster * (1 << page_cluster))
In that (swapout logic) it effecti
I'm trying to get more familiar with the MM code in 2.4.0, as can be
seen from lots of questions I have on the subject. I discovered nasty
mm behaviour under even moderate load (2.2 didn't have troubles).
Things go berzerk if you have one big process whose working set is
around your physical memo
Marcelo Tosatti <[EMAIL PROTECTED]> writes:
> On 7 Jan 2001, Zlatko Calusic wrote:
>
> > The following patch cleans up some obsolete structures from the mm &
> > proc code.
> >
> > Beside that it also fixes what I think is a bug:
> >
Rik van Riel <[EMAIL PROTECTED]> writes:
> On 7 Jan 2001, Zlatko Calusic wrote:
>
> > The following patch cleans up some obsolete structures from the
> > mm & proc code.
> >
> > Beside that it also fixes what I think is a bug:
> >
> >
Rik van Riel <[EMAIL PROTECTED]> writes:
> On 7 Jan 2001, Zlatko Calusic wrote:
>
> > OK, maybe I was too fast in concluding with that change. I'm
> > still trying to find out why is MM working bad in some
> > circumstances (see my other email to the list).
&g
Rik van Riel <[EMAIL PROTECTED]> writes:
> On 7 Jan 2001, Zlatko Calusic wrote:
>
> > Things go berzerk if you have one big process whose working set
> > is around your physical memory size.
>
> "go berzerk" in what way? Does the system cause lots
OK, take two. This patch:
o removes obsolete /proc entryes and other mm structures not used
anymore.
o adds new /proc/sys/vm/max-async-pages
o updates documentation
As the patch doesn't change any kernel vital functionality it is
completely safe. I don't know if it satisfies Linus' patch submi
Rik van Riel <[EMAIL PROTECTED]> writes:
> Now if 2.4 has worse _performance_ than 2.2 due to one
> reason or another, that I'd like to hear about ;)
>
Oh, well, it seems that I was wrong. :)
First test: hogmem 180 5 = allocate 180MB and dirty it 5 times (on a
192MB machine)
kernel | swap us
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Mon, 8 Jan 2001, Rik van Riel wrote:
>
> > On Sun, 7 Jan 2001, Wayne Whitney wrote:
> >
> > > Well, here is a workload that performs worse on 2.4.0 than on 2.2.19pre,
> >
> > > The typical machine is a dual Intel box with 512MB RAM and 512MB swap
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On 8 Jan 2001, Eric W. Biederman wrote:
>
> > Zlatko Calusic <[EMAIL PROTECTED]> writes:>
> > >
> > > Yes, but a lot more data on the swap also means degraded performance,
> > > because the dis
Simon Kirby <[EMAIL PROTECTED]> writes:
> On Tue, Jan 09, 2001 at 10:47:57AM -0800, Linus Torvalds wrote:
>
> > And this _is_ a downside, there's no question about it. There's the worry
> > about the potential loss of locality, but there's also the fact that you
> > effectively need a bigger swa
"Vlad Bolkhovitine" <[EMAIL PROTECTED]> writes:
> Here is updated info for 2.4.1pre3:
>
> Size is MB, BlkSz is Bytes, Read, Write, and Seeks are MB/sec
>
> with mmap()
>
> File Block Num Seq ReadRand Read Seq Write Rand Write
> DirSize SizeThr Rate (CPU%) Rate (C
Rik van Riel <[EMAIL PROTECTED]> writes:
> > Second test: kernel compile make -j32 (empirically this puts the
> > VM under load, but not excessively!)
> >
> > 2.2.17 -> make -j32 392.49s user 47.87s system 168% cpu 4:21.13 total
> > 2.4.0 -> make -j32 389.59s user 31.29s system 182% cpu 3:50.2
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Sun, 24 Dec 2000, Linus Torvalds wrote:
> >
> > Marco, would you mind changing the test in reclaim_page(), somewheer
> > around line mm/vmscan.c:487 that says:
>
Speaking of page_launder() I just stumbled upon two oopsen today on
the UP build. Ma
Rik van Riel <[EMAIL PROTECTED]> writes:
> On Mon, 25 Dec 2000, Dan Aloni wrote:
> > On 25 Dec 2000, Zlatko Calusic wrote:
> >
> > > Speaking of page_launder() I just stumbled upon two oopsen today on
> > > the UP build. Maybe it could give a hint to s
Index: 24012.6/drivers/media/radio/radio-gemtek.c
--- 24012.6/drivers/media/radio/radio-gemtek.c Thu, 14 Dec 2000 00:08:47 +0100
zcalusic (linux/P/d/1_radio-gemt 1.1.2.2.3.1 644)
+++ 24012.7(w)/drivers/media/radio/radio-gemtek.c Sat, 30 Dec 2000 12:06:56 +0100
+zcalusic (linux/P/d/1_radio-gemt 1
Rik van Riel <[EMAIL PROTECTED]> writes:
> Hi Linus, Alan, Mike,
>
> the following patch sets PF_MEMALLOC for the current task
> in __alloc_pages() to avoid infinite recursion when we try
> to free memory from __alloc_pages().
>
> Please apply the patch below, which fixes this (embarrasing)
> b
Mike Galbraith <[EMAIL PROTECTED]> writes:
> Hi,
>
> On Fri, 18 May 2001, Stephen C. Tweedie wrote:
>
> > That's the main problem with static parameters. The problem you are
> > trying to solve is fundamentally dynamic in most cases (which is also
> > why magic numbers tend to suck in the VM.)
For a long time I've been thinking that inactive list is too small,
while observing lots of different workloads (all I/O bound). Finally,
I decided to take a look and try to improve things. In mm/vmscan.c I
found this overly complicated piece of heuristics:
if (!target) {
int inactive = n
Ed Tomlinson <[EMAIL PROTECTED]> writes:
> Zlatko,
>
> Do you have your modified xmem available somewhere. Think it might be of
> interest to a few of us.
>
> TIA
> Ed Tomlinson <[EMAIL PROTECTED]>
>
For some time I've been trying to make a simple, yet functional web
page to put some stuff t
This patch removes the limit on the number of async pages in the
flight.
That artificial limit hurts both swap out and swap in path as it
introduces synchronization points (and/or weakens swapin readahead),
which I think are not necessary.
I also took an opportunity to clean up code a little bit
Marcelo Tosatti <[EMAIL PROTECTED]> writes:
> Zlatko,
>
> I've read your patch to remove nr_async_pages limit while reading an
> archive on the web. (I have to figure out why lkml is not being delivered
> correctly to me...)
>
> Quoting your message:
>
> "That artificial limit hurts both swa
Ed Tomlinson <[EMAIL PROTECTED]> writes:
[snip]
> Maybe we can have the best of both worlds. Is it possible to allocate the BH
> early and then defer the IO? The idea being to make IO possible without having
> to allocate. This would let us remove the async page limit but would ensure
> we cou
Mike Galbraith <[EMAIL PROTECTED]> writes:
> On Mon, 4 Jun 2001, Marcelo Tosatti wrote:
>
> > Zlatko,
> >
> > I've read your patch to remove nr_async_pages limit while reading an
> > archive on the web. (I have to figure out why lkml is not being delivered
> > correctly to me...)
> >
> > Quoting
Marcelo Tosatti <[EMAIL PROTECTED]> writes:
[snip]
> Exactly. And when we reach a low watermark of memory, we start writting
> out the anonymous memory.
>
Hm, my observations are a little bit different. I find that writeouts
happen sooner than the moment we reach low watermark, and many times
ju
Mike Galbraith <[EMAIL PROTECTED]> writes:
> On Fri, 8 Jun 2001, John Stoffel wrote:
>
> > Mike> OK, riddle me this. If this test is a crummy test, just how is
> > Mike> it that I was able to warn Rik in advance that when 2.4.5 was
> > Mike> released, he should expect complaints? How did I _k
Hi Eric and all!
Last few weeks or so I started having problems with reboot/poweroff on
my aging SMP desktop (dual PIII, Apollo Pro 266 chipset). The machine
does all steps til' the very end where it stops (hangs) before the
actual reboot or poweroff. The problem doesn't happen every time (but
occ
On 13.12.2013 15:10, Mel Gorman wrote:
Kicked this another bit today. It's still a bit half-baked but it restores
the historical performance and leaves the door open at the end for playing
nice with distributing file pages between nodes. Finishing this series
depends on whether we are going to ma
On 17.12.2013 22:23, Mel Gorman wrote:
On Tue, Dec 17, 2013 at 04:07:35PM +0100, Zlatko Calusic wrote:
On 13.12.2013 15:10, Mel Gorman wrote:
Kicked this another bit today. It's still a bit half-baked but it restores
the historical performance and leaves the door open at the end for pl
81 matches
Mail list logo
