All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.com>
To: Theodore Ts'o <tytso@mit.edu>, Matthew Wilcox <willy@infradead.org>
Cc: Michal Hocko <mhocko@kernel.org>,
	lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [ATTEND] many topics
Date: Tue, 24 Jan 2017 06:34:29 +1100	[thread overview]
Message-ID: <87mvehd0ze.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <20170123170924.ubx2honzxe7g34on@thunk.org>

[-- Attachment #1: Type: text/plain, Size: 1928 bytes --]

On Tue, Jan 24 2017, Theodore Ts'o wrote:

> On Sun, Jan 22, 2017 at 10:05:44PM -0800, Matthew Wilcox wrote:
>> 
>> I don't have a clear picture in my mind of when Java promotes objects
>> from nursery to tenure
>
> It's typically on the order of minutes.   :-)
>
>> ... which is not too different from my lack of
>> understanding of what the MM layer considers "temporary" :-)  Is it
>> acceptable usage to allocate a SCSI command (guaranteed to be freed
>> within 30 seconds) from the temporary area?  Or should it only be used
>> for allocations where the thread of control is not going to sleep between
>> allocation and freeing?
>
> What the mm folks have said is that it's to prevent fragmentation.  If
> that's the optimization, whether or not you the process is allocating
> the memory sleeps for a few hundred milliseconds, or even seconds, is
> really in the noise compared with the average lifetime of an inode in
> the inode cache, or a page in the page cache....
>
> Why do you think it matters whether or not we sleep?  I've not heard
> any explanation for the assumption for why this might be important.

Because "TEMPORARY" implies a limit to the amount of time, and sleeping
is the thing that causes a process to take a large amount of time.  It
seems like an obvious connection to me.

Imagine I want to allocate a large contiguous region in the
ZONE_MOVEABLE region.  I find a mostly free region, so I just need to
move those last few pages.  If there is a limit on how long a process
can sleep while holding an allocation from ZONE_MOVEABLE, then I know
how long, at most, I need to wait before those pages become either free
or movable.  If those processes can wait indefinitely, then I might have
to wait indefinitely to get this large region.

"temporary" doesn't mean anything without a well defined time limit.

But maybe I completely misunderstand.

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  reply	other threads:[~2017-01-23 19:34 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-18  5:49 [ATTEND] many topics Matthew Wilcox
2017-01-18 10:13 ` [Lsf-pc] " Jan Kara
2017-01-18 11:26   ` willy
2017-01-18 13:32 ` Michal Hocko
2017-01-19 11:05   ` willy
2017-01-19 11:33     ` Michal Hocko
2017-01-19 11:52       ` willy
2017-01-19 12:11         ` Michal Hocko
2017-01-21  0:11           ` NeilBrown
2017-01-21 13:16             ` Theodore Ts'o
2017-01-22  4:45               ` NeilBrown
2017-01-23  6:05                 ` Matthew Wilcox
2017-01-23  6:30                   ` NeilBrown
2017-01-23  6:35                     ` Matthew Wilcox
2017-01-23 17:09                   ` Theodore Ts'o
2017-01-23 19:34                     ` NeilBrown [this message]
2017-01-25 14:36                       ` Vlastimil Babka
2017-01-25 20:36                         ` Matthew Wilcox
2017-01-25 21:15                           ` Vlastimil Babka
2017-01-25 23:19                         ` NeilBrown
2017-01-26  8:56                           ` Michal Hocko
2017-01-26 21:20                             ` NeilBrown
2017-01-27 13:12                               ` Michal Hocko

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=87mvehd0ze.fsf@notabene.neil.brown.name \
    --to=neilb@suse.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=mhocko@kernel.org \
    --cc=tytso@mit.edu \
    --cc=willy@infradead.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.