> Well the GRU uses follow_page() instead of get_user_pages. Performance is
> a major issue for the GRU.
Worse, the GRU takes its TLB faults from within an interrupt so we
use follow_page to prevent going to sleep. That said, I think we
could probably use follow_page() with FOLL_GET set to
On Wed, Jan 30, 2008 at 11:19:28AM -0800, Christoph Lameter wrote:
> On Wed, 30 Jan 2008, Jack Steiner wrote:
>
> > Moving to a different lock solves the problem.
>
> Well it gets us back to the issue why we removed the lock. As Robin said
> before: If its global then we can have a huge number
On Wed, Jan 30, 2008 at 11:50:26AM -0800, Christoph Lameter wrote:
> On Wed, 30 Jan 2008, Andrea Arcangeli wrote:
>
> > XPMEM requires with invalidate_range (sleepy) +
> > before_invalidate_range (sleepy). invalidate_all should also be called
> > before_release (both sleepy).
> >
> > It sounds
This is the second part of a patch posted to patch 1/6.
Index: git-linus/mm/rmap.c
===
--- git-linus.orig/mm/rmap.c2008-01-30 11:55:56.0 -0600
+++ git-linus/mm/rmap.c 2008-01-30 12:01:28.0 -0600
@@ -476,8 +476,10
Back to one of Andrea's points from a couple days ago, I think we still
have a problem with the PageExternalRmap page flag.
If I had two drivers with external rmap implementations, there is no way
I can think of for a simple flag to coordinate a single page being
exported and maintained by the
On Wed, Jan 30, 2008 at 06:04:52PM +0100, Andrea Arcangeli wrote:
> On Wed, Jan 30, 2008 at 10:11:24AM -0600, Robin Holt wrote:
...
> > The three issues we need to simultaneously solve is revoking the remote
> > page table/tlb information while still in a sleepable context and
> Robin, if you don't mind, could you please post or upload somewhere
> your GPLv2 code that registers itself in Christoph's V2 notifiers? Or
> is it top secret? I wouldn't mind to have a look so I can better
> understand what's the exact reason you're sleeping besides attempting
> GFP_KERNEL
Robin, if you don't mind, could you please post or upload somewhere
your GPLv2 code that registers itself in Christoph's V2 notifiers? Or
is it top secret? I wouldn't mind to have a look so I can better
understand what's the exact reason you're sleeping besides attempting
GFP_KERNEL
On Wed, Jan 30, 2008 at 06:04:52PM +0100, Andrea Arcangeli wrote:
On Wed, Jan 30, 2008 at 10:11:24AM -0600, Robin Holt wrote:
...
The three issues we need to simultaneously solve is revoking the remote
page table/tlb information while still in a sleepable context and not
having the remote
Back to one of Andrea's points from a couple days ago, I think we still
have a problem with the PageExternalRmap page flag.
If I had two drivers with external rmap implementations, there is no way
I can think of for a simple flag to coordinate a single page being
exported and maintained by the
This is the second part of a patch posted to patch 1/6.
Index: git-linus/mm/rmap.c
===
--- git-linus.orig/mm/rmap.c2008-01-30 11:55:56.0 -0600
+++ git-linus/mm/rmap.c 2008-01-30 12:01:28.0 -0600
@@ -476,8 +476,10
On Wed, Jan 30, 2008 at 11:19:28AM -0800, Christoph Lameter wrote:
On Wed, 30 Jan 2008, Jack Steiner wrote:
Moving to a different lock solves the problem.
Well it gets us back to the issue why we removed the lock. As Robin said
before: If its global then we can have a huge number of
On Wed, Jan 30, 2008 at 11:50:26AM -0800, Christoph Lameter wrote:
On Wed, 30 Jan 2008, Andrea Arcangeli wrote:
XPMEM requires with invalidate_range (sleepy) +
before_invalidate_range (sleepy). invalidate_all should also be called
before_release (both sleepy).
It sounds we need full
Well the GRU uses follow_page() instead of get_user_pages. Performance is
a major issue for the GRU.
Worse, the GRU takes its TLB faults from within an interrupt so we
use follow_page to prevent going to sleep. That said, I think we
could probably use follow_page() with FOLL_GET set to
What is the status of getting invalidate_all adjusted to indicate a need
to also call _release?
Thanks,
Robin
On Mon, Jan 28, 2008 at 12:28:46PM -0800, Christoph Lameter wrote:
> when a task exits we can remove all external pts at once. At that point the
> extern mmu may also unregister itself
I don't understand how this is intended to work. I think the page flag
needs to be maintained by the mmu_notifier subsystem.
Let's assume we have a mapping that has a grant from xpmem and an
additional grant from kvm. The exporters are not important, the fact
that there may be two is.
Assume
I am going to seperate my comments into individual replies to help
reduce the chance they are lost.
> +void mmu_notifier_release(struct mm_struct *mm)
...
> + hlist_for_each_entry_safe_rcu(mn, n, t,
> + >mmu_notifier.head, hlist) {
> +
What is the status of getting invalidate_all adjusted to indicate a need
to also call _release?
Thanks,
Robin
On Mon, Jan 28, 2008 at 12:28:46PM -0800, Christoph Lameter wrote:
when a task exits we can remove all external pts at once. At that point the
extern mmu may also unregister itself
I am going to seperate my comments into individual replies to help
reduce the chance they are lost.
+void mmu_notifier_release(struct mm_struct *mm)
...
+ hlist_for_each_entry_safe_rcu(mn, n, t,
+ mm-mmu_notifier.head, hlist) {
+
I don't understand how this is intended to work. I think the page flag
needs to be maintained by the mmu_notifier subsystem.
Let's assume we have a mapping that has a grant from xpmem and an
additional grant from kvm. The exporters are not important, the fact
that there may be two is.
Assume
> +void mmu_notifier_release(struct mm_struct *mm)
...
> + hlist_for_each_entry_safe_rcu(mn, n, t,
> + >mmu_notifier.head, hlist) {
> + if (mn->ops->release)
> + mn->ops->release(mn, mm);
> +
+void mmu_notifier_release(struct mm_struct *mm)
...
+ hlist_for_each_entry_safe_rcu(mn, n, t,
+ mm-mmu_notifier.head, hlist) {
+ if (mn-ops-release)
+ mn-ops-release(mn, mm);
+
> void mmu_notifier_register(struct mmu_notifier *mn, struct mm_struct *mm)
> {
> - spin_lock(_notifier_list_lock);
> - hlist_add_head(>hlist, >mmu_notifier.head);
> - spin_unlock(_notifier_list_lock);
> + down_write(>mmap_sem);
> + __mmu_notifier_register(mn, mm);
> +
> > > 1. invalidate_all()
> >
> > That will be fine as long as we can unregister the ops notifier and free
> > the structure. Otherwise, we end up being called needlessly.
>
> No you cannot do that because there are still callbacks that come later.
> The invalidate_all may lead to
1. invalidate_all()
That will be fine as long as we can unregister the ops notifier and free
the structure. Otherwise, we end up being called needlessly.
No you cannot do that because there are still callbacks that come later.
The invalidate_all may lead to invalidate_range() doing
void mmu_notifier_register(struct mmu_notifier *mn, struct mm_struct *mm)
{
- spin_lock(mmu_notifier_list_lock);
- hlist_add_head(mn-hlist, mm-mmu_notifier.head);
- spin_unlock(mmu_notifier_list_lock);
+ down_write(mm-mmap_sem);
+ __mmu_notifier_register(mn, mm);
+
On Fri, Jan 25, 2008 at 11:03:07AM -0800, Christoph Lameter wrote:
> > > > Shouldn't this really be protected by the down_write(mmap_sem)? Maybe:
> > >
> > > Ok. We could switch this to mmap_sem protection for the mm_struct but the
> > > rmap notifier is not associated with an mm_struct. So we
On Fri, Jan 25, 2008 at 10:47:04AM -0800, Christoph Lameter wrote:
> On Fri, 25 Jan 2008, Robin Holt wrote:
>
> > I realize it is a minor nit, but since we put the continuation in column
> > 81 in the next define, can we do the same here and make this more
> > reada
> +#define mmu_notifier(function, mm, args...) \
...
> + if (__mn->ops->function)\
> + __mn->ops->function(__mn, \
> + mm,
On Fri, Jan 25, 2008 at 12:42:29PM +0100, Andrea Arcangeli wrote:
> On a technical merit this still partially makes me sick and I think
> it's the last issue to debate.
>
> @@ -971,6 +974,9 @@ int try_to_unmap(struct page *page, int
> else
> ret = try_to_unmap_file(page,
On Fri, Jan 25, 2008 at 11:03:07AM -0800, Christoph Lameter wrote:
Shouldn't this really be protected by the down_write(mmap_sem)? Maybe:
Ok. We could switch this to mmap_sem protection for the mm_struct but the
rmap notifier is not associated with an mm_struct. So we would need to
On Fri, Jan 25, 2008 at 12:42:29PM +0100, Andrea Arcangeli wrote:
On a technical merit this still partially makes me sick and I think
it's the last issue to debate.
@@ -971,6 +974,9 @@ int try_to_unmap(struct page *page, int
else
ret = try_to_unmap_file(page,
+#define mmu_notifier(function, mm, args...) \
...
+ if (__mn-ops-function)\
+ __mn-ops-function(__mn, \
+ mm, \
+
On Fri, Jan 25, 2008 at 10:47:04AM -0800, Christoph Lameter wrote:
On Fri, 25 Jan 2008, Robin Holt wrote:
I realize it is a minor nit, but since we put the continuation in column
81 in the next define, can we do the same here and make this more
readable?
We need to fix the next define
this is getting
to the point where we can start testing. It does compile now.
I am traveling tomorrow but should be able to get back to this tomorrow
evening or early Friday.
Thank you for your attention,
Robin Holt
Index: mmu_notifiers/include/linux/export_notifier.h
or early Friday. This has not even been compiled yet. Just
marking it up for now.
Thank you for your attention,
Robin Holt
Index: mmu_notifiers/include/linux/export_notifier.h
===
--- /dev/null 1970-01-01 00:00:00.0 +
On Wed, Jan 23, 2008 at 11:48:43AM -0800, Christoph Lameter wrote:
> On Wed, 23 Jan 2008, Andrea Arcangeli wrote:
>
> > On Wed, Jan 23, 2008 at 04:52:47AM -0600, Robin Holt wrote:
> > > But 100 callouts holding spinlocks will not work for our implementation
> > > and
On Wed, Jan 23, 2008 at 03:35:54PM +0100, Gerd Hoffmann wrote:
> Robin Holt wrote:
> > We have a seg structure which is similar to some structure you probably
> > have which describes the grant. One of the things hanging off that
> > seg structure is essentially a page
On Wed, Jan 23, 2008 at 03:12:36PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> >> That would render the notifies useless for Xen too. Xen needs to
> >> intercept the actual pte clear and instead of just zapping it use the
> >> hypercall to do the unmap and release the grant.
> >
> > We are tackling
On Wed, Jan 23, 2008 at 01:51:23PM +0100, Gerd Hoffmann wrote:
> Jumping in here, looks like this could develop into a direction useful
> for Xen.
>
> Background: Xen has a mechanism called "grant tables" for page sharing.
> Guest #1 can issue a "grant" for another guest #2, which in turn then
> Why don't you stick to mm+va and use get_user_pages and let the VM do
> the swapins etc...?
Our concern is also with memory protections for the physical page.
Additionally, we need to support exporting of memory in a VM_PFNMAP
address ranges (specifically, memory mapped using sgi_fetchop,
Christoph, Maybe you can clear one thing up. Was this proposal an
addition to or replacement of Andrea's? I assumed an addition. I am
going to try to restrict my responses to ones appropriate for that
assumption.
> The remote instance is like a secondary TLB what you're doing in your
> code is
On Wed, Jan 23, 2008 at 12:27:57PM +0200, Avi Kivity wrote:
>> The approach with the export notifier is page based not based on the
>> mm_struct. We only need a single page count for a page that is exported to
>> a number of remote instances of linux. The page count is dropped when all
>> the
On Wed, Jan 23, 2008 at 12:27:57PM +0200, Avi Kivity wrote:
The approach with the export notifier is page based not based on the
mm_struct. We only need a single page count for a page that is exported to
a number of remote instances of linux. The page count is dropped when all
the remote
Christoph, Maybe you can clear one thing up. Was this proposal an
addition to or replacement of Andrea's? I assumed an addition. I am
going to try to restrict my responses to ones appropriate for that
assumption.
The remote instance is like a secondary TLB what you're doing in your
code is
Why don't you stick to mm+va and use get_user_pages and let the VM do
the swapins etc...?
Our concern is also with memory protections for the physical page.
Additionally, we need to support exporting of memory in a VM_PFNMAP
address ranges (specifically, memory mapped using sgi_fetchop,
On Wed, Jan 23, 2008 at 01:51:23PM +0100, Gerd Hoffmann wrote:
Jumping in here, looks like this could develop into a direction useful
for Xen.
Background: Xen has a mechanism called grant tables for page sharing.
Guest #1 can issue a grant for another guest #2, which in turn then
can use
On Wed, Jan 23, 2008 at 03:35:54PM +0100, Gerd Hoffmann wrote:
Robin Holt wrote:
We have a seg structure which is similar to some structure you probably
have which describes the grant. One of the things hanging off that
seg structure is essentially a page table containing PFNs
On Wed, Jan 23, 2008 at 11:48:43AM -0800, Christoph Lameter wrote:
On Wed, 23 Jan 2008, Andrea Arcangeli wrote:
On Wed, Jan 23, 2008 at 04:52:47AM -0600, Robin Holt wrote:
But 100 callouts holding spinlocks will not work for our implementation
and even if the callouts are made
or early Friday. This has not even been compiled yet. Just
marking it up for now.
Thank you for your attention,
Robin Holt
Index: mmu_notifiers/include/linux/export_notifier.h
===
--- /dev/null 1970-01-01 00:00:00.0 +
this is getting
to the point where we can start testing. It does compile now.
I am traveling tomorrow but should be able to get back to this tomorrow
evening or early Friday.
Thank you for your attention,
Robin Holt
Index: mmu_notifiers/include/linux/export_notifier.h
cleanup is equivalent to the cleanup of
a page we have never used.
Thanks,
Robin Holt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
have never used.
Thanks,
Robin Holt
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
for a SIGTERM,
SIGKILL, or something along that line interrupting the core dump process.
Is this the correct direction to take? Are there any better ideas for
handling this?
Thanks,
Robin Holt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
for a SIGTERM,
SIGKILL, or something along that line interrupting the core dump process.
Is this the correct direction to take? Are there any better ideas for
handling this?
Thanks,
Robin Holt
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
Is there any way on typical motherboards to send an NMI? On Altix boxes,
we can use the system controller to send an NMI. I have found some
motherboards appear to have an NMI line. Is there anything like that
on i386? Maybe I am missing the issue entirely. Does deadlock inside
an IRQ handler
Is there any way on typical motherboards to send an NMI? On Altix boxes,
we can use the system controller to send an NMI. I have found some
motherboards appear to have an NMI line. Is there anything like that
on i386? Maybe I am missing the issue entirely. Does deadlock inside
an IRQ handler
problems occur inside the interrupt handlers.
What can I do to help troubleshoot this problem.
Thanks,
Robin Holt
PS: A little background information:
# lspci -v
...
00:0b.0 Mass storage controller: Promise Technology, Inc. PDC40718 (SATA 300
TX4) (rev 02)
Subsystem: Promise Technology, Inc
problems occur inside the interrupt handlers.
What can I do to help troubleshoot this problem.
Thanks,
Robin Holt
PS: A little background information:
# lspci -v
...
00:0b.0 Mass storage controller: Promise Technology, Inc. PDC40718 (SATA 300
TX4) (rev 02)
Subsystem: Promise Technology, Inc
On Tue, Aug 28, 2007 at 07:02:35PM +0100, Christoph Hellwig wrote:
> Big fat NACK, for dirty VM tricks, playing with task_struct lifetimes,
> and last but not least the horrible ioctl "API".
The ioctl is sort of historical. IIRC, in ProPack 3 (RHEL4 based 2.4
kernel), we added system calls.
On Tue, Aug 28, 2007 at 07:02:35PM +0100, Christoph Hellwig wrote:
Big fat NACK, for dirty VM tricks, playing with task_struct lifetimes,
and last but not least the horrible ioctl API.
The ioctl is sort of historical. IIRC, in ProPack 3 (RHEL4 based 2.4
kernel), we added system calls. When
On Mon, Aug 27, 2007 at 08:35:10PM +0100, Al Viro wrote:
> On Mon, Aug 27, 2007 at 02:19:06PM -0500, Dean Nelson wrote:
>
> > No operations can be done once it's closed, only while it's opened.
>
> What the hell do you mean, can't be done?
>
> fd = open(...);
> fp =
On Mon, Aug 27, 2007 at 08:35:10PM +0100, Al Viro wrote:
On Mon, Aug 27, 2007 at 02:19:06PM -0500, Dean Nelson wrote:
No operations can be done once it's closed, only while it's opened.
What the hell do you mean, can't be done?
fd = open(...);
fp = popen(/bin/date, r);
of the loop and
simply loops until T0_CMP has changed (a tick has happened).
Signed-off-by: Robin Holt <[EMAIL PROTECTED]>
Index: apic_fixes/arch/x86_64/kernel/apic.c
===
--- apic_fixes.orig/arch/x86_64/kernel/apic.c 2007-07
of the loop and
simply loops until T0_CMP has changed (a tick has happened).
Signed-off-by: Robin Holt [EMAIL PROTECTED]
Index: apic_fixes/arch/x86_64/kernel/apic.c
===
--- apic_fixes.orig/arch/x86_64/kernel/apic.c 2007-07-26 15:45
On Wed, May 30, 2007 at 12:46:58AM +1000, Stephen Rothwell wrote:
> On Tue, 29 May 2007 06:48:16 -0700 Stephane Eranian <[EMAIL PROTECTED]> wrote:
> >
> > Only in linux-2.6.22/Documentation: perfmon2.txt
>
> Did part of the patch go missing?
>
> > diff --exclude=.git -urp
On Wed, May 30, 2007 at 12:46:58AM +1000, Stephen Rothwell wrote:
On Tue, 29 May 2007 06:48:16 -0700 Stephane Eranian [EMAIL PROTECTED] wrote:
Only in linux-2.6.22/Documentation: perfmon2.txt
Did part of the patch go missing?
diff --exclude=.git -urp --exclude-from=/tmp/excl315935
On Fri, May 18, 2007 at 09:50:03AM +0200, Andrea Righi wrote:
> Rik van Riel wrote:
> > Andrea Righi wrote:
> >> I'm looking for a way to keep track of the processes that fail to
> >> allocate new
> >> virtual memory. What do you think about the following approach
> >> (untested)?
> >
> > Looks
On Fri, May 18, 2007 at 09:50:03AM +0200, Andrea Righi wrote:
Rik van Riel wrote:
Andrea Righi wrote:
I'm looking for a way to keep track of the processes that fail to
allocate new
virtual memory. What do you think about the following approach
(untested)?
Looks like an easy way for
On Tue, Apr 17, 2007 at 08:45:03PM +0200, Andi Kleen wrote:
>
> > Is there any movement on this?
>
> I'm open to reasonable patches for the hooks at least. If that is done
> then the actual kgdb code can be reviewed and considered eventually too.
Would you be open to adding to that set of
On Fri, Apr 20, 2007 at 08:23:39AM +0200, Jes Sorensen wrote:
> Andrew Morton wrote:
> >Another driver which should be fully converted to the kthread API:
> >kthread_stop() and kthread_should_stop().
> >
> >And according to my logs, this driver was added to the tree more than
> >a year _after_ the
On Fri, Apr 20, 2007 at 08:23:39AM +0200, Jes Sorensen wrote:
Andrew Morton wrote:
Another driver which should be fully converted to the kthread API:
kthread_stop() and kthread_should_stop().
And according to my logs, this driver was added to the tree more than
a year _after_ the kthread
On Tue, Apr 17, 2007 at 08:45:03PM +0200, Andi Kleen wrote:
Is there any movement on this?
I'm open to reasonable patches for the hooks at least. If that is done
then the actual kgdb code can be reviewed and considered eventually too.
Would you be open to adding to that set of hooks the
On Mon, Apr 09, 2007 at 06:35:39PM -0600, Eric W. Biederman wrote:
> Robin Holt <[EMAIL PROTECTED]> writes:
>
> > OK. I just got the OK from management. The system we were booting was
> > for research only. We had NR_CPUS=num_online_cpus()=4096 which we
On Mon, Apr 09, 2007 at 06:48:54PM -0600, Eric W. Biederman wrote:
> Andrew Morton <[EMAIL PROTECTED]> writes:
>
> > I suspect there are quite a few kernel threads which don't really need to
> > be threads at all: the code would quite happily work if it was changed to
> > use keventd, via
On Mon, Apr 09, 2007 at 06:48:54PM -0600, Eric W. Biederman wrote:
Andrew Morton [EMAIL PROTECTED] writes:
I suspect there are quite a few kernel threads which don't really need to
be threads at all: the code would quite happily work if it was changed to
use keventd, via schedule_work()
On Mon, Apr 09, 2007 at 06:35:39PM -0600, Eric W. Biederman wrote:
Robin Holt [EMAIL PROTECTED] writes:
OK. I just got the OK from management. The system we were booting was
for research only. We had NR_CPUS=num_online_cpus()=4096 which were
non-hyperthreaded. With no attached I/O
OK. I just got the OK from management. The system we were booting was
for research only. We had NR_CPUS=num_online_cpus()=4096 which were
non-hyperthreaded. With no attached I/O and the tweak I originally
posted plus one change Jack has already gotten accepted, the machine
booted in approx 12
On Mon, Apr 09, 2007 at 08:36:21AM -0600, Eric W. Biederman wrote:
> Robin Holt <[EMAIL PROTECTED]> writes:
>
> > I would say this is more a benefit than a problem. With a couple of these
> > systems we are testing, the number of kernel threads is far greater tha
On Mon, Apr 09, 2007 at 01:06:43PM +0400, Oleg Nesterov wrote:
> On 04/08, Eric W. Biederman wrote:
> > There is a practical question how much we care about pstree being
> > confused (I assume it doesn't crash). If this is just a confusion
> > issue then I say go for it. PPID == 0 is a very
On Mon, Apr 09, 2007 at 01:06:43PM +0400, Oleg Nesterov wrote:
On 04/08, Eric W. Biederman wrote:
There is a practical question how much we care about pstree being
confused (I assume it doesn't crash). If this is just a confusion
issue then I say go for it. PPID == 0 is a very legitimate
On Mon, Apr 09, 2007 at 08:36:21AM -0600, Eric W. Biederman wrote:
Robin Holt [EMAIL PROTECTED] writes:
I would say this is more a benefit than a problem. With a couple of these
systems we are testing, the number of kernel threads is far greater than
the number of user processes
OK. I just got the OK from management. The system we were booting was
for research only. We had NR_CPUS=num_online_cpus()=4096 which were
non-hyperthreaded. With no attached I/O and the tweak I originally
posted plus one change Jack has already gotten accepted, the machine
booted in approx 12
On Fri, Apr 06, 2007 at 09:38:24AM -0600, Eric W. Biederman wrote:
> How hard is tasklist_lock hit on these systems?
The major hold-off we are seeing is from tasks reaping children,
especially tasks with very large children lists.
> How hard is the pid hash hit on these systems?
In the little
> So I think we have some options once we get the kernel threads out
> of the way. Getting the kernel threads out of the way would seem
> to be the first priority.
I think both avenues would probably be the right way to proceeed.
Getting kthreads to not be parented by init would be an
So I think we have some options once we get the kernel threads out
of the way. Getting the kernel threads out of the way would seem
to be the first priority.
I think both avenues would probably be the right way to proceeed.
Getting kthreads to not be parented by init would be an opportunity
On Fri, Apr 06, 2007 at 09:38:24AM -0600, Eric W. Biederman wrote:
How hard is tasklist_lock hit on these systems?
The major hold-off we are seeing is from tasks reaping children,
especially tasks with very large children lists.
How hard is the pid hash hit on these systems?
In the little bit
ill reaping zombied tasks more than 30 seconds
following command completion. With this patch, all the zombied tasks
are removed within the first couple seconds.
Any suggestions would be greatly appreciated.
Thanks,
Robin Holt
Patch against 2.6.16 SLES 10 kernel.
Index: linux-2.6.16/kernel/exi
machine init is still reaping zombied tasks more than 30 seconds
following command completion. With this patch, all the zombied tasks
are removed within the first couple seconds.
Any suggestions would be greatly appreciated.
Thanks,
Robin Holt
Patch against 2.6.16 SLES 10 kernel.
Index: linux
On Fri, Mar 09, 2007 at 05:58:59PM -0600, Nathan Lynch wrote:
> Hello-
>
> Cliff Wickman wrote:
> > This patch would insert a preference to migrate such a task to a cpu within
> > its cpuset (and set its cpus_allowed to its cpuset).
> >
> > With this patch, migrate the task to:
> > 1) to any
On Fri, Mar 09, 2007 at 05:58:59PM -0600, Nathan Lynch wrote:
Hello-
Cliff Wickman wrote:
This patch would insert a preference to migrate such a task to a cpu within
its cpuset (and set its cpus_allowed to its cpuset).
With this patch, migrate the task to:
1) to any cpu on the same
On Mon, Mar 12, 2007 at 04:12:32AM -0700, Christoph Lameter wrote:
> On Sun, 11 Mar 2007, David Miller wrote:
> > The reason is that every time I've monitored the allocation patterns
> > of these things on SMP, the page table chunks always get released on a
> > different cpu than where they were
On Mon, Mar 12, 2007 at 04:12:32AM -0700, Christoph Lameter wrote:
On Sun, 11 Mar 2007, David Miller wrote:
The reason is that every time I've monitored the allocation patterns
of these things on SMP, the page table chunks always get released on a
different cpu than where they were
On Wed, Feb 21, 2007 at 11:33:31AM +, David Howells wrote:
> Kawai, Hidehiro <[EMAIL PROTECTED]> wrote:
>
> > Is coredump_setting_sem a global semaphore? If so, it prevents concurrent
> > core dumping.
>
> No, it doesn't. Look again:
>
> int do_coredump(long signr, int exit_code,
On Wed, Feb 21, 2007 at 11:33:31AM +, David Howells wrote:
Kawai, Hidehiro [EMAIL PROTECTED] wrote:
Is coredump_setting_sem a global semaphore? If so, it prevents concurrent
core dumping.
No, it doesn't. Look again:
int do_coredump(long signr, int exit_code, struct pt_regs
On Tue, Feb 20, 2007 at 10:58:17AM +, David Howells wrote:
> Kawai, Hidehiro <[EMAIL PROTECTED]> wrote:
> Actually, I don't think the locking is that hard or that complex.
>
> int do_coredump(long signr, int exit_code, struct pt_regs * regs)
> {
>
>
>
On Tue, Feb 20, 2007 at 10:58:17AM +, David Howells wrote:
Kawai, Hidehiro [EMAIL PROTECTED] wrote:
Actually, I don't think the locking is that hard or that complex.
int do_coredump(long signr, int exit_code, struct pt_regs * regs)
{
setup vars
On Fri, Feb 16, 2007 at 03:05:35PM +, David Howells wrote:
> Actually, I think I would just pass the mm pointer you have into maydump() and
> let that dereference it here:
>
> > + if (omit_anon_shared) {
>
> which would then be:
>
> if (mm->coredump_omit_anon_shared)
On Fri, Feb 16, 2007 at 03:05:35PM +, David Howells wrote:
Actually, I think I would just pass the mm pointer you have into maydump() and
let that dereference it here:
+ if (omit_anon_shared) {
which would then be:
if (mm-coredump_omit_anon_shared) {
How
On Tue, Jan 30, 2007 at 04:36:34PM +0900, Kawai, Hidehiro wrote:
> Hi Robin,
>
> Robin Holt wrote:
> > Can you make this a little more transparent? Having a magic bitmask does
> > not seem like the best way to do stuff. Could you maybe make a core_flags
> > dir
601 - 700 of 747 matches
Mail list logo
