From: Evgeniy Polyakov <johnpol@2ka•mipt.ru>
To: Andrew Morton <akpm@linux-foundation•org>
Cc: linux-kernel@vger•kernel.org, netdev@vger•kernel.org,
linux-fsdevel@vger•kernel.org
Subject: Re: POHMELFS high performance network filesystem. Transactions, failover, performance.
Date: Wed, 14 May 2008 11:40:30 +0400 [thread overview]
Message-ID: <20080514074028.GA28330@2ka.mipt.ru> (raw)
In-Reply-To: <20080513233341.47edea7f.akpm@linux-foundation.org>
Hi Andrew.
On Tue, May 13, 2008 at 11:33:41PM -0700, Andrew Morton (akpm@linux-foundation•org) wrote:
> If any thread takes more than one kmap() at a time, it is deadlockable.
> Because there is a finite pool of kmaps. Everyone can end up holding
> one or more kmaps, then waiting for someone else to release one.
It never takes the whole LAST_PKMAP maps. So the same can be applied to
any user who kmaps at least one page - while user waits for free slot,
it can be reused by someone else and so on.
But it can be speed issue, on 32 bit machine with 8gb of ram essentially
all pages were highmem and required mapping, so this does slows things
down (probably a lot), so I will extend writeback path of the POHMELFS
not to kmap pages, but instead use ->sendpage(), which if needed will
map page one-by-one. Current approach when page is mapped and then
copied looks really beter since the only one sending function is used
which takes lock only single time.
> Duplicating page_waitqueue() is bad. Exporting it is probably bad too.
> Better would be to help us work out why the core kernel infrastructure is
> unsuitable, then make it suitable.
When ->writepage() is used, it has to wait until page is written (remote
side sent acknowledge), so if multiple pages are being written
simultaneously we either have to allocate shared structure or use
per-page wait. Right now there are transactions (and they will be used
for all operations eventually), so this waiting can go away.
It is exactly the same logic which lock_page() uses.
Will lock_page_killable()/__lock_page_killable() be exported to modules?
--
Evgeniy Polyakov
next prev parent reply other threads:[~2008-05-14 7:41 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-13 17:45 POHMELFS high performance network filesystem. Transactions, failover, performance Evgeniy Polyakov
2008-05-13 19:09 ` Jeff Garzik
2008-05-13 20:51 ` Evgeniy Polyakov
2008-05-14 0:52 ` Jamie Lokier
2008-05-14 1:16 ` Florian Wiessner
2008-05-14 8:10 ` Evgeniy Polyakov
2008-05-14 7:57 ` Evgeniy Polyakov
2008-05-14 13:35 ` Sage Weil
2008-05-14 13:52 ` Evgeniy Polyakov
2008-05-14 14:31 ` Jamie Lokier
2008-05-14 15:00 ` Evgeniy Polyakov
2008-05-14 19:08 ` Jeff Garzik
2008-05-14 19:32 ` Evgeniy Polyakov
2008-05-14 20:37 ` Jeff Garzik
2008-05-14 21:19 ` Evgeniy Polyakov
2008-05-14 21:34 ` Jeff Garzik
2008-05-14 21:32 ` Jamie Lokier
2008-05-14 21:37 ` Jeff Garzik
2008-05-14 21:43 ` Jamie Lokier
2008-05-14 22:02 ` Evgeniy Polyakov
2008-05-14 22:28 ` Jamie Lokier
2008-05-14 22:45 ` Evgeniy Polyakov
2008-05-15 1:10 ` Jamie Lokier
2008-05-15 7:34 ` Evgeniy Polyakov
2008-05-14 19:05 ` Jeff Garzik
2008-05-14 21:38 ` Jamie Lokier
2008-05-14 19:03 ` Jeff Garzik
2008-05-14 19:38 ` Evgeniy Polyakov
2008-05-14 21:57 ` Jamie Lokier
2008-05-14 22:06 ` Jeff Garzik
2008-05-14 22:41 ` Evgeniy Polyakov
2008-05-14 22:50 ` Evgeniy Polyakov
2008-05-14 22:32 ` Evgeniy Polyakov
2008-05-14 14:09 ` Jamie Lokier
2008-05-14 16:09 ` Sage Weil
2008-05-14 19:11 ` Jeff Garzik
2008-05-14 21:19 ` Jamie Lokier
2008-05-14 18:24 ` Jeff Garzik
2008-05-14 20:00 ` Sage Weil
2008-05-14 21:49 ` Jeff Garzik
2008-05-14 22:26 ` Sage Weil
2008-05-14 22:35 ` Jamie Lokier
2008-05-14 6:33 ` Andrew Morton
2008-05-14 7:40 ` Evgeniy Polyakov [this message]
2008-05-14 8:01 ` Andrew Morton
2008-05-14 8:31 ` Evgeniy Polyakov
2008-05-14 8:08 ` Evgeniy Polyakov
2008-05-14 13:41 ` Sage Weil
2008-05-14 13:56 ` Evgeniy Polyakov
2008-05-14 17:56 ` Andrew Morton
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=20080514074028.GA28330@2ka.mipt.ru \
--to=johnpol@2ka$(echo .)mipt.ru \
--cc=akpm@linux-foundation$(echo .)org \
--cc=linux-fsdevel@vger$(echo .)kernel.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox