> From: Rene Herman [mailto:[EMAIL PROTECTED]
> ftruncate there and some similarity to a problem I once experienced
I can't honestly say I completely grasp the fundamentals of the issue you
experienced but we are using ext3 with data=journal
-
To unsubscribe from this list: send the line "unsubs
> From: Nick Piggin [mailto:[EMAIL PROTECTED]
> Can you try getting the output of /proc/vmstat as well?
Ouput from vmstat, meminfo and bloatmon below.
vmstat
nr_dirty 0
nr_writeback 0
nr_unstable 0
nr_page_table_pages 361
nr_mapped 33077
nr_slab 8107
pgpgin 1433195947
pgpgout 148795046
pswpin 0
p
> From: Linus Torvalds [mailto:[EMAIL PROTECTED]
> I actually suspect you should be _fairly_ close to such a situation
We run with min_free_kbytes set around 4k to answer your earlier question.
> Louis, exactly how do you allocate that big 1.6GB shared area?
Ummm, shm_open, ftruncate, mmap ? Is
> From: Nick Piggin [mailto:[EMAIL PROTECTED]
> I'd be interested to know how OOM and page reclaim behaves after these
> patches
> (or with a newer kernel).
We didn't get far today. The various suggestions everyone has for solving
this problem spurred several new discussions inside the office and
> From: Horst H. von Brand [mailto:[EMAIL PROTECTED]
> How do you /know/ it won't just be recycled in the production case?
In the production case is when oom fires and kills things. I can only assume
memory is not being freed fast enough otherwise oom wouldn't get so upset.
> That is your ultimat
> From: Tim Schmielau [mailto:[EMAIL PROTECTED]
> I believe your OOM problem is not connected to these observations. There
I don't know what to tell you except oom fires only when the update runs. I
know it's a pitiful datapoint so I'll work on getting more data.
-
To unsubscribe from this list:
> From: Jeffrey Hundstad [mailto:[EMAIL PROTECTED]
> POSIX_FADV_NOREUSE flags. It seems these would cause the tar and patch
WI may be naïve as well, but that sounds interesting. Unless someone knows
of an obvious reason this won't work we can make a one-off tar command and
give it a whirl.
-
To
> From: Horst H. von Brand [mailto:[EMAIL PROTECTED]
> That means that there isn't a need for that memory at all (and so they
In the current isolated non-production, not actually bearing a load test
case yes. But if I can't get it to not swap on an idle system I have no hope
of avoiding OOM on a
> From: David Lang [mailto:[EMAIL PROTECTED]
> I think that I am seeing two seperate issues here that are getting mixed
> up.
Fair enough.
> however the real problem that Aucoin is running into is patching process
> (tar, etc) kicks off the system is choosing to use it's
F
> From: Nick Piggin [mailto:[EMAIL PROTECTED]
> We had customers see similar incorrect OOM problems, so I sent in some
> patches merged after 2.6.16. Can you upgrade to latest kernel? (otherwise
> I guess backporting could be an option for you).
I will raise the question of moving the kernel forwa
> PS: No need to put a copy of the entire message
Apologies for the lapse in protocol.
> The point you're missing is that an "inactive" page is a free
> page that happens to have known clean data on it
I understand now where the inactive page count is coming from.
I don't understand why there
the
feeling that twisting them all tight would make the housekeeping algorithms
more aggressive.
What, if anything, besides manually echoing a "3" to drop_caches will cause
all those inactive pages to be put back on the free list ?
-Original Message-
From: Aucoin [mailto:[EMAIL
down the untar and verify process
because the disk I/O we really care about is not on any of the OS
partitions.
Louis Aucoin
-Original Message-
From: Tim Schmielau [mailto:[EMAIL PROTECTED]
Sent: Sunday, December 03, 2006 2:47 PM
To: Aucoin
Cc: 'Andrew Morton'; [EMAIL PROT
w Morton [mailto:[EMAIL PROTECTED]
Sent: Sunday, December 03, 2006 2:09 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; [EMAIL PROTECTED]
Subject: Re: la la la la ... swappiness
> On Sun, 3 Dec 2006 00:16:38 -0600 "Aucoin" <[EMAIL PROTECTED]> wrot
Reformatted as plain text.
From: Aucoin [mailto:[EMAIL PROTECTED]
Sent: Sunday, December 03, 2006 12:17 AM
To: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'; 'linux-kernel@vger.kernel.org';
'[EMAIL PROTECTED]'
Su
15 matches
Mail list logo
