[lkml]   [2000]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
SubjectRe: [patch-2.4.0-test12-pre5] optimized get_empty_filp()
On Tue, 5 Dec 2000, Peter Samuelson wrote:
> The question is whether or not it is worth taking a lock again (with
> that non-zero cost) to achieve the gain of doing the 92-byte memset and
> the atomic_set in parallel with other CPUs. In other words, by locking
> and unlocking twice, you reduce the contention on the lock. Is this,
> however, worth the extra cycles and bus traffic? I don't know.

Ok, that's a different (opposite) question and so if the answer previously
was "Yes" then obviously the answer to this one is "No". I.e. it is not
worth retaking the lock for the sake of reducing contention on the
lock. And it is not just a couple of extra instructions but it is also a
bus lock (or cache lock if you are lucky, on P6 only). And that is exactly
what my patch does -- removes the unnecessary bus locking and at least 2


PS. Your previous statement (when clarified and explained by you in this
message) made me think that you misread the patch, i.e. saw "+" when there
was "-" -- I removed those lines and not added them... Here is the patch
again for you to see it clearer:

--- linux/fs/file_table.c Fri Nov 17 19:36:27 2000
+++ work/fs/file_table.c Tue Dec 5 16:52:06 2000
@@ -40,13 +40,11 @@
- file_list_unlock();
memset(f, 0, sizeof(*f));
f->f_version = ++event;
f->f_uid = current->fsuid;
f->f_gid = current->fsgid;
- file_list_lock();
list_add(&f->f_list, &anon_list);
return f;
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:51    [W:0.351 / U:2.464 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site