All of lore.kernel.org
 help / color / mirror / Atom feed
From: William Lee Irwin III <wli@holomorphy.com>
To: Andrew Morton <akpm@digeo.com>
Cc: davidm@hpl.hp.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: 2.5.69-mm4
Date: Tue, 13 May 2003 17:15:36 -0700	[thread overview]
Message-ID: <20030514001536.GE8978@holomorphy.com> (raw)
In-Reply-To: <20030512225504.4baca409.akpm@digeo.com>

On Mon, May 12, 2003 at 10:55:04PM -0700, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.69/2.5.69-mm4/
> Lots of small things.
> thread-info-in-task_struct.patch
>   allow thread_info to be allocated as part of task_struct

AIUI the task_cache is meant to prevent certain task_t (dear gawd I
can't stand those _struct suffixes) refcounting pathologies because
the task_t has its final put done by the task itself or something
on that order, so it may be better for ia64 to adapt the task_cache to
their purposes instead of wiping it entirely. Also, making the
task_cache treatment uniform apart from its declaration would allow the
#ifdef to be shoved in a header.

Alternatively, one could alter the timing of the final put on a task_t
so as to handle it similarly to the final mmput() (though here, too it
might be more sightly to #ifdef the necessary bits in headers).

I think there are already outstanding task_t refcounting bugs, so I'm
not entirely sure where we stand wrt. changing final put mechanics.

-- wli

WARNING: multiple messages have this Message-ID (diff)
From: William Lee Irwin III <wli@holomorphy.com>
To: Andrew Morton <akpm@digeo.com>
Cc: davidm@hpl.hp.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: 2.5.69-mm4
Date: Tue, 13 May 2003 17:15:36 -0700	[thread overview]
Message-ID: <20030514001536.GE8978@holomorphy.com> (raw)
In-Reply-To: <20030512225504.4baca409.akpm@digeo.com>

On Mon, May 12, 2003 at 10:55:04PM -0700, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.69/2.5.69-mm4/
> Lots of small things.
> thread-info-in-task_struct.patch
>   allow thread_info to be allocated as part of task_struct

AIUI the task_cache is meant to prevent certain task_t (dear gawd I
can't stand those _struct suffixes) refcounting pathologies because
the task_t has its final put done by the task itself or something
on that order, so it may be better for ia64 to adapt the task_cache to
their purposes instead of wiping it entirely. Also, making the
task_cache treatment uniform apart from its declaration would allow the
#ifdef to be shoved in a header.

Alternatively, one could alter the timing of the final put on a task_t
so as to handle it similarly to the final mmput() (though here, too it
might be more sightly to #ifdef the necessary bits in headers).

I think there are already outstanding task_t refcounting bugs, so I'm
not entirely sure where we stand wrt. changing final put mechanics.

-- wli
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

  parent reply	other threads:[~2003-05-14  0:02 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-13  5:55 2.5.69-mm4 Andrew Morton
2003-05-13  5:55 ` 2.5.69-mm4 Andrew Morton
2003-05-13  7:02 ` 2.5.69-mm4 Alexander Hoogerhuis
2003-05-13  7:11   ` 2.5.69-mm4 Andrew Morton
2003-05-13  7:11     ` 2.5.69-mm4 Andrew Morton
2003-05-13  8:00     ` 2.5.69-mm4 Alexander Hoogerhuis
2003-05-13  8:00       ` 2.5.69-mm4 Alexander Hoogerhuis
2003-05-13  8:55       ` 2.5.69-mm4 Helge Hafting
2003-05-13  8:55         ` 2.5.69-mm4 Helge Hafting
2003-05-13  9:04         ` 2.5.69-mm4 Andrew Morton
2003-05-13  9:04           ` 2.5.69-mm4 Andrew Morton
2003-05-13 14:05           ` [PATCH] Re: 2.5.69-mm4 undefined active_load_balance Helge Hafting
2003-05-13 14:05             ` Helge Hafting
2003-05-13 16:27             ` Helge Hafting
2003-05-13 16:27               ` Helge Hafting
2003-05-13 16:40               ` Helge Hafting
2003-05-13 16:40                 ` Helge Hafting
2003-05-13 19:38               ` William Lee Irwin III
2003-05-13 19:38                 ` William Lee Irwin III
2003-05-13 21:31                 ` Helge Hafting
2003-05-13 21:31                   ` Helge Hafting
2003-05-13 21:35                   ` William Lee Irwin III
2003-05-13 21:35                     ` William Lee Irwin III
2003-05-13 11:04         ` 2.5.69-mm4 Alexander Hoogerhuis
2003-05-13 11:04           ` 2.5.69-mm4 Alexander Hoogerhuis
2003-05-13 12:43       ` 2.5.69-mm4 Ed Tomlinson
2003-05-13 20:10         ` 2.5.69-mm4 Andrew Morton
     [not found]       ` <20030513011232.67c300d0.akpm@digeo.com>
2003-05-13 20:28         ` 2.5.69-mm4 Alexander Hoogerhuis
2003-05-13 21:53           ` 2.5.69-mm4 Andrew Morton
2003-05-13 22:24             ` 2.5.69-mm4 Matt Mackall
2003-05-14  6:18               ` 2.5.69-mm4 Alexander Hoogerhuis
2003-05-14  6:22             ` 2.5.69-mm4 Alexander Hoogerhuis
2003-05-14  6:29               ` 2.5.69-mm4 Andrew Morton
2003-05-14  7:15                 ` 2.5.69-mm4 Alexander Hoogerhuis
2003-05-13 17:08 ` 2.5.69-mm4 smp crash, seems fs/vm related Helge Hafting
2003-05-13 17:08   ` Helge Hafting
2003-05-13 20:17 ` 2.5.69-mm4 William Lee Irwin III
2003-05-13 20:17   ` 2.5.69-mm4 William Lee Irwin III
2003-05-13 20:25   ` 2.5.69-mm4 William Lee Irwin III
2003-05-13 20:25     ` 2.5.69-mm4 William Lee Irwin III
2003-05-14  0:15 ` William Lee Irwin III [this message]
2003-05-14  0:15   ` 2.5.69-mm4 William Lee Irwin III
2003-05-14  0:46   ` 2.5.69-mm4 David Mosberger
2003-05-14  0:46     ` 2.5.69-mm4 David Mosberger
  -- strict thread matches above, loose matches on Subject: below --
2003-05-13  9:53 2.5.69-mm4 Felipe Alfaro Solana
2003-05-13 22:14 2.5.69-mm4 Shane Shrybman

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=20030514001536.GE8978@holomorphy.com \
    --to=wli@holomorphy.com \
    --cc=akpm@digeo.com \
    --cc=davidm@hpl.hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --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.