From: ebiederm+eric@npwt.net (Eric W. Biederman)
To: Zlatko.Calusic@CARNet.hr
Cc: linux-mm@kvack.org
Subject: Re: Comments on shmfs-0.1.010
Date: 18 Jul 1998 11:03:10 -0500 [thread overview]
Message-ID: <m1r9zjjge9.fsf@flinx.npwt.net> (raw)
In-Reply-To: Zlatko Calusic's message of 18 Jul 1998 14:59:02 +0200
>>>>> "ZC" == Zlatko Calusic <Zlatko.Calusic@CARNet.hr> writes:
>> This is a normal case with no harm.
>> I think normal 2.1.101 should cause it too.
>> It's simply a result of swapping adding swap.
ZC> Well, it looks like it's harmless. I don't know why. :)
In that case it is harmless because it is reading the first page of
swap onto the swap lock! And since there are no races there the lock
isn't needed.
>> Are you creating really large files in shmfs?
ZC> Yes, I was creating very big file to test some things.
ZC> But after I applied my patch, I never saw those kmalloc messages?!
Currently all of pointers to file blocks are allocated just in kernel
memory. So really big files might cause that. I haven't seen them so
I haven't a clue.
ZC> Unfortunately not. Time for experimenting ran out. :(
Well that at least tells me which options were used to get those
performance marks.
ZC> Yesterday I tried to copy linux tree to /shm and got these errors:
ZC> Tree has around 4200 files (which is slightly more than inode limit on
ZC> Linux!). Few last files didn't get copied.
The story is that I allocate a fixed number of inodes to shmfs at mount time.
And then when I need one I look through those structures for one that is unused.
That is fine for testing my kernel patch, but in the long run it is a problem.
The temporary work around is to due:
mount -t shmfs -o inodes=10240 none /tmp
Anything less than 65535 should be legal.
The raw development version has a fix for this and a few other things
that I allocate in kernel memory, but it isn't stable yet. I'm using
the stable code to create my kernel patches.
Eric
--
This is a majordomo managed list. To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org
prev parent reply other threads:[~1998-07-18 15:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-07-16 22:03 Comments on shmfs-0.1.010 Zlatko Calusic
1998-07-18 0:50 ` Eric W. Biederman
1998-07-18 12:59 ` Zlatko Calusic
1998-07-18 16:03 ` Eric W. Biederman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1r9zjjge9.fsf@flinx.npwt.net \
--to=ebiederm+eric@npwt.net \
--cc=Zlatko.Calusic@CARNet.hr \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.