On Wed, Apr 13, 2005 at 03:47:40PM +0200, Andrea Arcangeli wrote:
> On Fri, Mar 18, 2005 at 11:12:18AM -0500, Noah Meyerhans wrote:
> > Well, that's certainly an interesting question. The filesystem is IBM's
> > JFS. If you tell me that's part of the problem, I'm not likely to
> > disagree. 8^)
On Fri, Mar 18, 2005 at 11:12:18AM -0500, Noah Meyerhans wrote:
> Well, that's certainly an interesting question. The filesystem is IBM's
> JFS. If you tell me that's part of the problem, I'm not likely to
> disagree. 8^)
It would be nice if you could reproduce with ext3 or reiserfs (if with
ex
Hi Andrew, Andrea, et al. Sorry for taking a while to get back to you
on this. Thanks a lot for the work you've already put in to this. We
built a 2.6.11.4 kernel with Andrea's first patch for this problem (the
patch is included at the end of this mail, just to make sure you know
which one I'm r
Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
>
> On Wed, Mar 16, 2005 at 04:04:35AM -0800, Andrew Morton wrote:
> > > + if (!reclaim_state->reclaimed_slab &&
> > > + zone->pages_scanned >= (zone->nr_active +
> > > + zone
On Wed, Mar 16, 2005 at 04:04:35AM -0800, Andrew Morton wrote:
> > + if (!reclaim_state->reclaimed_slab &&
> > + zone->pages_scanned >= (zone->nr_active +
> > + zone->nr_inactive) * 4)
> >
Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
>
> This below is an untested attempt at bringing dquot a bit more in line
> with the API, to make the whole thing a bit more consistent,
Like this? (Noah, don't bother testing this one)
Fix some bugs spotted by Andrea Arcangeli <[EMAIL PROTECTED]>
Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
>
> - ret = dqstats.allocated_dquots;
> +ret = (dqstats.free_dquots / 100) * sysctl_vfs_cache_pressure;
Oh I see. Yes, using .allocated_dquots was wrong.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> Still, I think it would make more sense to return a success indication from
> shrink_slab() if we actually freed any slab objects. That will prevent us
> from incorrectly going all_unreclaimable if all we happen to be doing is
> increasing slab inter
Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
>
> the VM is setting all_unreclaimable on the
> normal zone without any care about the progress we're making at freeing
> the slab.
Urgh, I didn't notice that all_unreclaimable is set.
> Beware this absolutely untested and it may not be enough. Perhap
On Wed, Mar 16, 2005 at 01:31:34AM +0100, Andrea Arcangeli wrote:
> In short I think we can start by trying this fix (which has some risk,
> since now it might become harder to detect an oom condition, but I don't
Some testing shows that oom conditions are still detected fine (I
expected this but
On Tue, Mar 15, 2005 at 03:44:13PM -0500, Noah Meyerhans wrote:
> Hello. We have a server, currently running 2.6.11-rc4, that is
> experiencing similar OOM problems to those described at
> http://groups-beta.google.com/group/fa.linux.kernel/msg/9633559fea029f6e
> and discussed further by several d
Noah Meyerhans <[EMAIL PROTECTED]> wrote:
>
> Active:12382 inactive:280459 dirty:214 writeback:0 unstable:0 free:2299
> slab:220221 mapped:12256 pagetables:122
Vast amounts of slab - presumably inode and dentries.
What sort of local filesystems are in use?
Can you take a copy of /proc/slabinfo
On Tue, 2005-03-15 at 16:56 -0500, Sean wrote:
> On Tue, March 15, 2005 3:44 pm, Noah Meyerhans said:
> > The machine in question is a dual Xeon system with 2 GB of RAM, 3.5 GB
> > of swap, and several TB of NFS exported filesystems. One notable point
> > is that this machine has been running in o
On Tue, March 15, 2005 3:44 pm, Noah Meyerhans said:
> Hello. We have a server, currently running 2.6.11-rc4, that is
> experiencing similar OOM problems to those described at
> http://groups-beta.google.com/group/fa.linux.kernel/msg/9633559fea029f6e
> and discussed further by several developers h
Hello. We have a server, currently running 2.6.11-rc4, that is
experiencing similar OOM problems to those described at
http://groups-beta.google.com/group/fa.linux.kernel/msg/9633559fea029f6e
and discussed further by several developers here (the summary is at
http://www.kerneltraffic.org/kernel-tr
15 matches
Mail list logo
