Telis,
I know I replied earlier saying this patch didn't help much, but that was
because I misapplied it. Correcting my original bug does fix this problem
for me! Thanks so much for the patch. I realize there is a trade-off involved
here, but our application is now very careful about how it uses
Sorry for the repost. It seems that when I tried to attach the kernel
data as an attached file the text of my mail message got clipped.
Many of you may have already seen this data, sorry for the repost, but
I was concerned that perhaps not all of my original email made it through.
Hopefully this
Aristotelis Iordanidis wrote:
> We've run into the same problem, working with an armnommu platform.
> We tracked down the root of the high cpu load to the function
> kswapd_balance_pgdat() in linux-2.4.x/mmnommu/vmscan.c.
> The problem occurs only when using the non-power-of-2 memory allocator
>
Phil Wilshire wrote:
> If you want to stream data buffers I would take a close look at relayfs
That's for streaming data between kernel and userspace.
What I'm doing is streaming from a filesystem on hard disk, which has
nothing to do with relayfs, and everything to do with the kernel's
file cac
Aristotelis Iordanidis wrote:
[body snipped]
Telis
Telis,
Thank you for this information. I have played around with this somewhat.
Modifying the number sent to schedule_timeout helped, but only a little.
Dave
--
David Spain
SiCortex, Inc.
Three Clock Tower Place, Suite 210
Maynard, MA USA
David McCullough wrote:
If you boot te hsystem is a configuration that doesn't use much RAM and
don't start and nasty big apps is the system idle (ie kswapd is
behaving). If so what triggers it's rampage ?
Cheers,
Davidm
Davidm,
This came out a bit garbled. I'm going to paraphrase and hope
Hi All,
This problem is close to my heart too.
On the Blackfin systems we have been working on slobs, slabs and even
(piece of)cake allocators inside the ever dynamic 2.6 kernel.
We were, I think close to a solution but I for one am having trouble
keeping any solution in line with kernel move
O/H David McCullough έγραψε:
Jivin Jamie Lokier lays it down ...
David McCullough wrote:
Feel free to send in some patches :-)
When they let me past the dark age of 2.4.26-uc0, maybe I will :-)
I have a few ideas to combine the better fragmentation performance of
page_alloc2.c
Jivin Jamie Lokier lays it down ...
> David McCullough wrote:
> > Feel free to send in some patches :-)
>
> When they let me past the dark age of 2.4.26-uc0, maybe I will :-)
>
> I have a few ideas to combine the better fragmentation performance of
> page_alloc2.c with the speed of page_alloc.c
David McCullough wrote:
> Feel free to send in some patches :-)
When they let me past the dark age of 2.4.26-uc0, maybe I will :-)
I have a few ideas to combine the better fragmentation performance of
page_alloc2.c with the speed of page_alloc.c (a hybrid of buddy and
bitmap search), plus some fr
On Wednesday 14 March 2007 7:35 pm, David McCullough wrote:
> If you boot te hsystem is a configuration that doesn't use much RAM and
> don't start and nasty big apps is the system idle (ie kswapd is
> behaving). If so what triggers it's rampage ?
I'd noticed this too (page_alloc2() high CPU use)
Jivin Jamie Lokier lays it down ...
> David Spain wrote:
> > I forgot to add the obligatory:
> >
> > uclinux-2.4.32-uc0 from the 20060803 drop.
> > Compiled with the gcc 2.95.3 binutils.
>
> page_alloc2.c is better for reducing fragmentation and also being less
> sensitive to it, but it doesn't
David Spain wrote:
> I forgot to add the obligatory:
>
> uclinux-2.4.32-uc0 from the 20060803 drop.
> Compiled with the gcc 2.95.3 binutils.
page_alloc2.c is better for reducing fragmentation and also being less
sensitive to it, but it doesn't interact with kswapd's wakeup logic in
quite the way
I forgot to add the obligatory:
uclinux-2.4.32-uc0 from the 20060803 drop.
Compiled with the gcc 2.95.3 binutils.
Dave
--
David Spain
SiCortex, Inc.
Three Clock Tower Place, Suite 210
Maynard, MA USA 01754 Email: [EMAIL PROTECTED]
___
14 matches
Mail list logo
