Actually we can just ditch it.
diff -puN fs/attr.c~inode_setattr-speedup fs/attr.c
--- 25/fs/attr.c~inode_setattr-speedup Thu May 29 14:01:54 2003
+++ 25-akpm/fs/attr.c Thu May 29 14:07:57 2003
@@ -81,7 +81,6 @@ int inode_setattr(struct inode * inode,
}
}
- lock_kernel();
if (ia_valid & ATTR_UID)
inode->i_uid = attr->ia_uid;
if (ia_valid & ATTR_GID)
@@ -93,12 +92,13 @@ int inode_setattr(struct inode * inode,
if (ia_valid & ATTR_CTIME)
inode->i_ctime = attr->ia_ctime;
if (ia_valid & ATTR_MODE) {
- inode->i_mode = attr->ia_mode;
+ umode_t mode = attr->ia_mode;
+
if (!in_group_p(inode->i_gid) && !capable(CAP_FSETID))
- inode->i_mode &= ~S_ISGID;
+ mode &= ~S_ISGID;
+ inode->i_mode = mode;
}
mark_inode_dirty(inode);
- unlock_kernel();
out:
return error;
}
> >> 20016 2619.9% __wake_up
> >> 19632 927.4% schedule
> >> 12204 0.0% .text.lock.sched
> >> 12128 0.0% start_this_handle
> >> 10011 0.0% journal_add_journal_head
> >
> > hm, lots of context switches still.
>
> I think that's ext3 busily kicking the living crap out of semaphores ;-)
But I deleted them all!. Well. There is one semaphore left in ext3/jbd,
and that is for serialisation around the oh-shit-we're-out-of-space
checkpointing code. I shall go on a hat diet if that is being a problem.
hmm, very odd.
You could try my "find out who's doing down() too much" patch:
diff -puN arch/i386/kernel/semaphore.c~down-diag arch/i386/kernel/semaphore.c
--- 25/arch/i386/kernel/semaphore.c~down-diag Thu May 29 14:11:46 2003
+++ 25-akpm/arch/i386/kernel/semaphore.c Thu May 29 14:12:18 2003
@@ -66,6 +66,7 @@ void __down(struct semaphore * sem)
sem->sleepers++;
for (;;) {
int sleepers = sem->sleepers;
+ static int count;
/*
* Add "everybody else" into it. They aren't
@@ -79,6 +80,10 @@ void __down(struct semaphore * sem)
sem->sleepers = 1; /* us - see -1 above */
spin_unlock_irqrestore(&sem->wait.lock, flags);
+ if (count++ > 100000) {
+ count = 0;
+ dump_stack();
+ }
schedule();
spin_lock_irqsave(&sem->wait.lock, flags);
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/