* Re: rmap15a swappy?
From: Sean Neakums @ 2002-12-12 21:21 UTC (permalink / raw)
To: linux-mm
In-Reply-To: <Pine.LNX.4.50L.0212121913030.17748-100000@imladris.surriel.com>
commence Rik van Riel quotation:
> On Thu, 12 Dec 2002, Sean Neakums wrote:
>
> Indeed, the older rmaps swapped later. However, swapping
> a little bit earlier turns out to be faster for almost all
> workloads.
Oh right, because if you get sudden memory pressure you have a bunch
of pages that you can just throw away without writeout?
Anyway, that's nifty. I just wanted to make sure it wasn't a
regression.
--
/ |
[|] Sean Neakums | Questions are a burden to others;
[|] <sneakums@zork.net> | answers a prison for oneself.
\ |
--
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/
^ permalink raw reply
* [BK PATCH 1/1] Remove NGROUPS hard limit (re-re-re-re-send)
From: Timothy Hockin @ 2002-12-12 21:29 UTC (permalink / raw)
To: torvalds, linux-kernel
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet 1.905 -> 1.906
# include/linux/kernel.h 1.27 -> 1.28
# lib/Makefile 1.15 -> 1.16
# include/linux/init_task.h 1.19 -> 1.20
# include/linux/sched.h 1.114 -> 1.115
# kernel/fork.c 1.92 -> 1.93
# kernel/sys.c 1.36 -> 1.37
# include/asm-i386/param.h 1.2 -> 1.3
# include/linux/sunrpc/svcauth.h 1.4 -> 1.5
# kernel/uid16.c 1.4 -> 1.5
# fs/proc/array.c 1.35 -> 1.36
# net/sunrpc/svcauth_unix.c 1.9 -> 1.10
# kernel/exit.c 1.76 -> 1.77
# include/linux/limits.h 1.3 -> 1.4
# fs/nfsd/auth.c 1.1 -> 1.2
# (new) -> 1.1 lib/bsearch.c
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 02/12/04 thockin@freakshow.cobalt.com 1.906
# Remove the limit of 32 groups. We now have a per-task, dynamic array of
# groups, which is kept sorted and refcounted. If the task has less than 32
# groups, we behave like older kernels and use an inline array.
#
# This ChangeSet incorporates all the core functionality. but does not fixup
# all the incorrect architecture usages of groups.
# --------------------------------------------
#
diff -Nru a/fs/nfsd/auth.c b/fs/nfsd/auth.c
--- a/fs/nfsd/auth.c Wed Dec 4 17:30:43 2002
+++ b/fs/nfsd/auth.c Wed Dec 4 17:30:43 2002
@@ -10,12 +10,15 @@
#include <linux/sunrpc/svcauth.h>
#include <linux/nfsd/nfsd.h>
+extern asmlinkage long sys_setgroups(int gidsetsize, gid_t *grouplist);
+
#define CAP_NFSD_MASK (CAP_FS_MASK|CAP_TO_MASK(CAP_SYS_RESOURCE))
void
nfsd_setuser(struct svc_rqst *rqstp, struct svc_export *exp)
{
struct svc_cred *cred = &rqstp->rq_cred;
int i;
+ gid_t groups[SVC_CRED_NGROUPS];
if (rqstp->rq_userset)
return;
@@ -29,7 +32,7 @@
cred->cr_uid = exp->ex_anon_uid;
if (!cred->cr_gid)
cred->cr_gid = exp->ex_anon_gid;
- for (i = 0; i < NGROUPS; i++)
+ for (i = 0; i < SVC_CRED_NGROUPS; i++)
if (!cred->cr_groups[i])
cred->cr_groups[i] = exp->ex_anon_gid;
}
@@ -42,13 +45,13 @@
current->fsgid = cred->cr_gid;
else
current->fsgid = exp->ex_anon_gid;
- for (i = 0; i < NGROUPS; i++) {
+ for (i = 0; i < SVC_CRED_NGROUPS; i++) {
gid_t group = cred->cr_groups[i];
if (group == (gid_t) NOGROUP)
break;
- current->groups[i] = group;
+ groups[i] = group;
}
- current->ngroups = i;
+ sys_setgroups(i, groups);
if ((cred->cr_uid)) {
cap_t(current->cap_effective) &= ~CAP_NFSD_MASK;
diff -Nru a/fs/proc/array.c b/fs/proc/array.c
--- a/fs/proc/array.c Wed Dec 4 17:30:43 2002
+++ b/fs/proc/array.c Wed Dec 4 17:30:43 2002
@@ -172,7 +172,7 @@
p->files ? p->files->max_fds : 0);
task_unlock(p);
- for (g = 0; g < p->ngroups; g++)
+ for (g = 0; g < min(p->ngroups, OLD_NGROUPS); g++)
buffer += sprintf(buffer, "%d ", p->groups[g]);
buffer += sprintf(buffer, "\n");
diff -Nru a/include/asm-i386/param.h b/include/asm-i386/param.h
--- a/include/asm-i386/param.h Wed Dec 4 17:30:43 2002
+++ b/include/asm-i386/param.h Wed Dec 4 17:30:43 2002
@@ -13,10 +13,6 @@
#define EXEC_PAGESIZE 4096
-#ifndef NGROUPS
-#define NGROUPS 32
-#endif
-
#ifndef NOGROUP
#define NOGROUP (-1)
#endif
diff -Nru a/include/linux/init_task.h b/include/linux/init_task.h
--- a/include/linux/init_task.h Wed Dec 4 17:30:43 2002
+++ b/include/linux/init_task.h Wed Dec 4 17:30:43 2002
@@ -80,6 +80,7 @@
.real_timer = { \
.function = it_real_fn \
}, \
+ .ngroups = 0, \
.cap_effective = CAP_INIT_EFF_SET, \
.cap_inheritable = CAP_INIT_INH_SET, \
.cap_permitted = CAP_FULL_SET, \
diff -Nru a/include/linux/kernel.h b/include/linux/kernel.h
--- a/include/linux/kernel.h Wed Dec 4 17:30:43 2002
+++ b/include/linux/kernel.h Wed Dec 4 17:30:43 2002
@@ -216,4 +216,7 @@
#define __FUNCTION__ (__func__)
#endif
+void *bsearch(const void *key, const void *base, size_t nmemb, size_t size,
+ int (*compar)(const void *, const void *));
+
#endif
diff -Nru a/include/linux/limits.h b/include/linux/limits.h
--- a/include/linux/limits.h Wed Dec 4 17:30:43 2002
+++ b/include/linux/limits.h Wed Dec 4 17:30:43 2002
@@ -3,7 +3,6 @@
#define NR_OPEN 1024
-#define NGROUPS_MAX 32 /* supplemental group IDs are available */
#define ARG_MAX 131072 /* # bytes of args + environ for exec() */
#define CHILD_MAX 999 /* no limit :-) */
#define OPEN_MAX 256 /* # open files a process may have */
@@ -18,5 +17,7 @@
#define XATTR_LIST_MAX 65536 /* size of extended attribute namelist (64k) */
#define RTSIG_MAX 32
+
+#define OLD_NGROUPS 32 /* old limit of supplemental group IDs */
#endif
diff -Nru a/include/linux/sched.h b/include/linux/sched.h
--- a/include/linux/sched.h Wed Dec 4 17:30:43 2002
+++ b/include/linux/sched.h Wed Dec 4 17:30:43 2002
@@ -276,6 +276,8 @@
typedef struct prio_array prio_array_t;
struct backing_dev_info;
+#define NGROUPS_INLINE 32
+
struct task_struct {
volatile long state; /* -1 unrunnable, 0 runnable, >0 stopped */
struct thread_info *thread_info;
@@ -348,7 +350,9 @@
uid_t uid,euid,suid,fsuid;
gid_t gid,egid,sgid,fsgid;
int ngroups;
- gid_t groups[NGROUPS];
+ gid_t *groups;
+ gid_t groups_inline[NGROUPS_INLINE];
+ atomic_t *groups_refcount;
kernel_cap_t cap_effective, cap_inheritable, cap_permitted;
int keep_capabilities:1;
struct user_struct *user;
diff -Nru a/include/linux/sunrpc/svcauth.h b/include/linux/sunrpc/svcauth.h
--- a/include/linux/sunrpc/svcauth.h Wed Dec 4 17:30:43 2002
+++ b/include/linux/sunrpc/svcauth.h Wed Dec 4 17:30:43 2002
@@ -14,10 +14,11 @@
#include <linux/sunrpc/msg_prot.h>
#include <linux/sunrpc/cache.h>
+#define SVC_CRED_NGROUPS 32
struct svc_cred {
uid_t cr_uid;
gid_t cr_gid;
- gid_t cr_groups[NGROUPS];
+ gid_t cr_groups[SVC_CRED_NGROUPS];
};
struct svc_rqst; /* forward decl */
diff -Nru a/kernel/exit.c b/kernel/exit.c
--- a/kernel/exit.c Wed Dec 4 17:30:43 2002
+++ b/kernel/exit.c Wed Dec 4 17:30:43 2002
@@ -57,6 +57,7 @@
return proc_dentry;
}
+extern void groups_free(gid_t *groups, int gidsetsize);
void release_task(struct task_struct * p)
{
struct dentry *proc_dentry;
@@ -66,6 +67,12 @@
if (p != current)
wait_task_inactive(p);
+
+ if (p->ngroups > NGROUPS_INLINE
+ && atomic_dec_and_test(p->groups_refcount)) {
+ kfree(p->groups_refcount);
+ groups_free(p->groups, p->ngroups);
+ }
atomic_dec(&p->user->processes);
security_task_free(p);
diff -Nru a/kernel/fork.c b/kernel/fork.c
--- a/kernel/fork.c Wed Dec 4 17:30:43 2002
+++ b/kernel/fork.c Wed Dec 4 17:30:43 2002
@@ -832,6 +832,13 @@
*/
clear_tsk_thread_flag(p, TIF_SYSCALL_TRACE);
+ /* increment the groups ref count */
+ if (p->ngroups > NGROUPS_INLINE) {
+ atomic_inc(p->groups_refcount);
+ } else if (p->ngroups) {
+ p->groups = p->groups_inline;
+ }
+
/* Our parent execution domain becomes current domain
These must match for thread signalling to apply */
diff -Nru a/kernel/sys.c b/kernel/sys.c
--- a/kernel/sys.c Wed Dec 4 17:30:43 2002
+++ b/kernel/sys.c Wed Dec 4 17:30:43 2002
@@ -21,6 +21,8 @@
#include <linux/times.h>
#include <linux/security.h>
#include <linux/dcookies.h>
+#include <linux/vmalloc.h>
+#include <linux/slab.h>
#include <asm/uaccess.h>
#include <asm/io.h>
@@ -1062,42 +1064,137 @@
return i;
}
+/* a simple shell-metzner sort */
+static void groupsort(gid_t *grouplist, int gidsetsize)
+{
+ int base, max, stride;
+
+ for (stride = 1; stride < gidsetsize; stride = 3 * stride + 1)
+ ; /* nothing */
+ stride /= 3;
+
+ while (stride) {
+ max = gidsetsize - stride;
+ for (base = 0; base < max; base++) {
+ int left = base;
+ gid_t tmp = grouplist[base + stride];
+ while (left >= 0 && tmp < grouplist[left]) {
+ grouplist[left] = grouplist[left + stride];
+ left -= stride;
+ }
+ grouplist[left + stride] = tmp;
+ }
+ stride /= 3;
+ }
+}
+
+static int gid_t_cmp(const void *a, const void *b)
+{
+ return *((gid_t *)a) - *((gid_t *)b);
+}
+
+#define GROUPS_KV_THRESH (2*EXEC_PAGESIZE/sizeof(gid_t))
+gid_t *groups_alloc(int gidsetsize)
+{
+ if (gidsetsize <= GROUPS_KV_THRESH)
+ return kmalloc(gidsetsize * sizeof(gid_t), GFP_KERNEL);
+ else
+ return vmalloc(gidsetsize * sizeof(gid_t));
+}
+
+void groups_free(gid_t *groups, int gidsetsize)
+{
+ if (gidsetsize <= NGROUPS_INLINE)
+ ; /* nothing */
+ else if (gidsetsize <= GROUPS_KV_THRESH)
+ kfree(groups);
+ else
+ vfree(groups);
+}
+
/*
- * SMP: Our groups are not shared. We can copy to/from them safely
+ * SMP: Our groups are copy-on-write. We can set them safely
* without another task interfering.
*/
-
-asmlinkage long sys_setgroups(int gidsetsize, gid_t *grouplist)
+int do_setgroups(int gidsetsize, gid_t *grouplist)
{
- gid_t groups[NGROUPS];
+ atomic_t *newrefcnt = NULL;
int retval;
- if (!capable(CAP_SETGID))
- return -EPERM;
- if ((unsigned) gidsetsize > NGROUPS)
- return -EINVAL;
- if(copy_from_user(groups, grouplist, gidsetsize * sizeof(gid_t)))
- return -EFAULT;
- retval = security_task_setgroups(gidsetsize, groups);
- if (retval)
+ BUG_ON(gidsetsize && !grouplist);
+
+ retval = security_task_setgroups(gidsetsize, grouplist);
+ if (retval) {
+ groups_free(grouplist, gidsetsize);
return retval;
- memcpy(current->groups, groups, gidsetsize * sizeof(gid_t));
+ }
+
+ if (gidsetsize > NGROUPS_INLINE) {
+ newrefcnt = kmalloc(sizeof(*newrefcnt), GFP_KERNEL);
+ if (!newrefcnt) {
+ groups_free(grouplist, gidsetsize);
+ return -ENOMEM;
+ }
+ atomic_set(newrefcnt, 1);
+ }
+ if (gidsetsize) {
+ /* sort the grouplist for faster searches */
+ groupsort(grouplist, gidsetsize);
+ }
+
+ /* disassociate ourselves from any shared group list */
+ if (current->ngroups > NGROUPS_INLINE
+ && atomic_dec_and_test(current->groups_refcount)) {
+ kfree(current->groups_refcount);
+ groups_free(current->groups, current->ngroups);
+ }
+
+ /* use the inline array for small numbers of groups */
+ if (gidsetsize <= NGROUPS_INLINE) {
+ memcpy(current->groups_inline, grouplist,
+ gidsetsize * sizeof(gid_t));
+ grouplist = current->groups_inline;
+ }
+
+ current->groups = grouplist;
+ current->groups_refcount = newrefcnt;
current->ngroups = gidsetsize;
+
return 0;
}
+
+asmlinkage long sys_setgroups(int gidsetsize, gid_t *grouplist)
+{
+ gid_t *groups = NULL;
+ gid_t groups_ar[NGROUPS_INLINE];
+
+ if (!capable(CAP_SETGID))
+ return -EPERM;
+ if (gidsetsize) {
+ if (gidsetsize <= NGROUPS_INLINE) {
+ groups = groups_ar;
+ } else {
+ groups = groups_alloc(gidsetsize);
+ if (!groups)
+ return -ENOMEM;
+ }
+
+ if (copy_from_user(groups, grouplist,
+ gidsetsize * sizeof(gid_t))) {
+ groups_free(groups, gidsetsize);
+ return -EFAULT;
+ }
+ }
+
+ return do_setgroups(gidsetsize, groups);
+}
static int supplemental_group_member(gid_t grp)
{
- int i = current->ngroups;
-
- if (i) {
- gid_t *groups = current->groups;
- do {
- if (*groups == grp)
- return 1;
- groups++;
- i--;
- } while (i);
+ if (current->ngroups) {
+ if (bsearch(&grp, current->groups, current->ngroups,
+ sizeof(gid_t), gid_t_cmp))
+ return 1;
}
return 0;
}
@@ -1390,3 +1487,4 @@
EXPORT_SYMBOL(unregister_reboot_notifier);
EXPORT_SYMBOL(in_group_p);
EXPORT_SYMBOL(in_egroup_p);
+EXPORT_SYMBOL(sys_setgroups);
diff -Nru a/kernel/uid16.c b/kernel/uid16.c
--- a/kernel/uid16.c Wed Dec 4 17:30:43 2002
+++ b/kernel/uid16.c Wed Dec 4 17:30:43 2002
@@ -13,6 +13,8 @@
#include <linux/init.h>
#include <linux/highuid.h>
#include <linux/security.h>
+#include <linux/slab.h>
+#include <linux/vmalloc.h>
#include <asm/uaccess.h>
@@ -107,45 +109,73 @@
return sys_setfsgid((gid_t)gid);
}
+extern gid_t *groups_alloc(int gidsetsize);
+extern void groups_free(gid_t *groups, int gidsetsize);
+extern int do_setgroups(int gidsetsize, gid_t *grouplist);
+
asmlinkage long sys_getgroups16(int gidsetsize, old_gid_t *grouplist)
{
- old_gid_t groups[NGROUPS];
+ old_gid_t *groups;
int i,j;
if (gidsetsize < 0)
return -EINVAL;
i = current->ngroups;
- if (gidsetsize) {
+ if (i && gidsetsize) {
if (i > gidsetsize)
return -EINVAL;
+ groups = vmalloc(i * sizeof(old_gid_t));
+ if (!groups)
+ return -ENOMEM;
for(j=0;j<i;j++)
groups[j] = current->groups[j];
- if (copy_to_user(grouplist, groups, sizeof(old_gid_t)*i))
+ if (copy_to_user(grouplist, groups, sizeof(old_gid_t)*i)) {
+ vfree(groups);
return -EFAULT;
+ }
+ vfree(groups);
}
return i;
}
asmlinkage long sys_setgroups16(int gidsetsize, old_gid_t *grouplist)
{
- old_gid_t groups[NGROUPS];
- gid_t new_groups[NGROUPS];
+ old_gid_t *groups;
+ gid_t *new_groups = NULL;
+ gid_t new_groups_ar[NGROUPS_INLINE];
int i;
if (!capable(CAP_SETGID))
return -EPERM;
- if ((unsigned) gidsetsize > NGROUPS)
- return -EINVAL;
- if (copy_from_user(groups, grouplist, gidsetsize * sizeof(old_gid_t)))
- return -EFAULT;
- for (i = 0 ; i < gidsetsize ; i++)
- new_groups[i] = (gid_t)groups[i];
- i = security_task_setgroups(gidsetsize, new_groups);
- if (i)
- return i;
- memcpy(current->groups, new_groups, gidsetsize * sizeof(gid_t));
- current->ngroups = gidsetsize;
- return 0;
+ if (gidsetsize) {
+ groups = vmalloc(gidsetsize * sizeof(old_gid_t));
+ if (!groups)
+ return -ENOMEM;
+
+ if (copy_from_user(groups, grouplist,
+ gidsetsize * sizeof(old_gid_t))) {
+ vfree(groups);
+ return -EFAULT;
+ }
+
+ if (gidsetsize <= NGROUPS_INLINE) {
+ new_groups = new_groups_ar;
+ } else {
+ new_groups = groups_alloc(gidsetsize);
+ if (!new_groups) {
+ vfree(groups);
+ return -ENOMEM;
+ }
+ }
+
+ for (i = 0; i < gidsetsize; i++)
+ new_groups[i] = (gid_t)groups[i];
+
+ vfree(groups);
+ }
+
+ /* this handles the allocated new_groups */
+ return do_setgroups(gidsetsize, new_groups);
}
asmlinkage long sys_getuid16(void)
diff -Nru a/lib/Makefile b/lib/Makefile
--- a/lib/Makefile Wed Dec 4 17:30:43 2002
+++ b/lib/Makefile Wed Dec 4 17:30:43 2002
@@ -9,11 +9,11 @@
L_TARGET := lib.a
export-objs := cmdline.o dec_and_lock.o rwsem-spinlock.o rwsem.o \
- crc32.o rbtree.o radix-tree.o kobject.o
+ crc32.o rbtree.o radix-tree.o kobject.o bsearch.o
obj-y := errno.o ctype.o string.o vsprintf.o brlock.o cmdline.o \
bust_spinlocks.o rbtree.o radix-tree.o dump_stack.o \
- kobject.o
+ kobject.o bsearch.o
obj-$(CONFIG_RWSEM_GENERIC_SPINLOCK) += rwsem-spinlock.o
obj-$(CONFIG_RWSEM_XCHGADD_ALGORITHM) += rwsem.o
diff -Nru a/lib/bsearch.c b/lib/bsearch.c
--- /dev/null Wed Dec 31 16:00:00 1969
+++ b/lib/bsearch.c Wed Dec 4 17:30:43 2002
@@ -0,0 +1,49 @@
+/* Copyright (C) 1991, 1992, 1997, 2000 Free Software Foundation, Inc.
+ This file is part of the GNU C Library.
+
+ The GNU C Library is free software; you can redistribute it and/or
+ modify it under the terms of the GNU Library General Public License as
+ published by the Free Software Foundation; either version 2 of the
+ License, or (at your option) any later version.
+
+ The GNU C Library is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Library General Public License for more details.
+
+ You should have received a copy of the GNU Library General Public
+ License along with the GNU C Library; see the file COPYING.LIB. If not,
+ write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ Boston, MA 02111-1307, USA. */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+
+/* Perform a binary search for KEY in BASE which has NMEMB elements
+ of SIZE bytes each. The comparisons are done by (*COMPAR)(). */
+void *
+bsearch(const void *key, const void *base, size_t nmemb, size_t size,
+ int (*compar)(const void *, const void *))
+{
+ size_t l, u, idx;
+ const void *p;
+ int comparison;
+
+ l = 0;
+ u = nmemb;
+ while (l < u) {
+ idx = (l + u) / 2;
+ p = (void *)(((const char *)base) + (idx * size));
+ comparison = (*compar)(key, p);
+ if (comparison < 0)
+ u = idx;
+ else if (comparison > 0)
+ l = idx + 1;
+ else
+ return (void *)p;
+ }
+
+ return NULL;
+}
+
+EXPORT_SYMBOL(bsearch);
diff -Nru a/net/sunrpc/svcauth_unix.c b/net/sunrpc/svcauth_unix.c
--- a/net/sunrpc/svcauth_unix.c Wed Dec 4 17:30:43 2002
+++ b/net/sunrpc/svcauth_unix.c Wed Dec 4 17:30:43 2002
@@ -401,11 +401,11 @@
if (slen > 16 || (len -= (slen + 2)*4) < 0)
goto badcred;
for (i = 0; i < slen; i++)
- if (i < NGROUPS)
+ if (i < SVC_CRED_NGROUPS)
cred->cr_groups[i] = ntohl(svc_getu32(argv));
else
svc_getu32(argv);
- if (i < NGROUPS)
+ if (i < SVC_CRED_NGROUPS)
cred->cr_groups[i] = NOGROUP;
if (svc_getu32(argv) != RPC_AUTH_NULL || svc_getu32(argv) != 0) {
^ permalink raw reply
* [BK SUMMARY] Remove NGROUPS hard limit (re-re-re-re-send)
From: Timothy Hockin @ 2002-12-12 21:28 UTC (permalink / raw)
To: torvalds, linux-kernel
Linus,
This patch removes the hard NGROUPS limit. It has been in use in a similar
form on our systems for some time.
There is a small change needed for glibc, and I will send that patch to the
glibc people when this gets pulled.
Unlike some prior versions of this patch, I have changed qsort() to a simple
non-recursive sort. Several people indicated that this change would solve
their objections. I have also changed the behavior of sys_setgroups to use an
inline array of gid_t for small sets of groups. Larger sets of groups use
kmalloc, and very large sets use vmalloc. This has turned up a big speed
increase for the (admittedly stupid) test of setgroups() in a loop with random
data and sets of 1-32 items, repeated hundreds of thousands of times, as well
as the tests of setgroups with random set sizes between 1 and 10000.
Lastly, this does not fixup all the architectures. I have or will soon have
other patchsets for that, which need to be reviewed by arch maintainers.
Tim
Please do a
bk pull http://suncobalt.bkbits.net/ngroups-2.5
This will update the following files:
fs/nfsd/auth.c | 11 +--
fs/proc/array.c | 2
include/asm-i386/param.h | 4 -
include/linux/init_task.h | 1
include/linux/kernel.h | 3
include/linux/limits.h | 3
include/linux/sched.h | 6 +
include/linux/sunrpc/svcauth.h | 3
kernel/exit.c | 7 +
kernel/fork.c | 7 +
kernel/sys.c | 144 ++++++++++++++++++++++++++++++++++-------
kernel/uid16.c | 64 +++++++++++++-----
lib/Makefile | 4 -
lib/bsearch.c | 49 +++++++++++++
net/sunrpc/svcauth_unix.c | 4 -
15 files changed, 256 insertions(+), 56 deletions(-)
through these ChangeSets (diffs in separate email):
<thockin@freakshow.cobalt.com> (02/12/04 1.906)
Remove the limit of 32 groups. We now have a per-task, dynamic array of
groups, which is kept sorted and refcounted. If the task has less than 32
groups, we behave like older kernels and use an inline array.
This ChangeSet incorporates all the core functionality. but does not fixup
all the incorrect architecture usages of groups.
^ permalink raw reply
* Re: Is this going to be true ?
From: Kjartan Maraas @ 2002-12-12 21:24 UTC (permalink / raw)
To: hps; +Cc: linux-kernel
In-Reply-To: <at8jcm$n8u$1@forge.intermeta.de>
tor, 2002-12-12 kl. 00:57 skrev Henning P. Schmiedehausen:
> mru@users.sourceforge.net (=?iso-8859-1?q?M=E5ns_Rullg=E5rd?=) writes:
>
> >> Competition is always good. It inpires people to do better.
>
> >Doing better than MS isn't much of an inspiration to me.
>
> There are no similar applications like the Exchange Server or the
> BizTalk server for Linux. I'd see them port all of the server portions
Wrt BizTalk...doesn't BEA Weblogic do just about anything that this
server application can and then some? I guess there are a few other
players in this field that are more friendly to Linux also.
Cheers
Kjartan
^ permalink raw reply
* Re: Adventure - the answer to what went wrong?
From: Alan Cox @ 2002-12-12 21:15 UTC (permalink / raw)
To: Dan Olson; +Cc: Linux 8086
In-Reply-To: <20021212122436.C57693-100000@agora.rdrop.com>
On Thu, 2002-12-12 at 20:27, Dan Olson wrote:
> Also, the file size is 84k, but that doesn't mean that the code segment is
> going to be more than 64k, does it? Does the whole file get loaded into
> memory and executed, or can there be other "stuff" in that file besides
> executable code that may not get loaded into the code segment? I haven't
> messed with this stuff in a while, so I don't remember :)
"size" should tell you.
Basically you have code at CS:0 for upto 64K (and possibly shared). Then
you have data at DS:0->n and stack at DS:[topsize] going down and the
dynamic memory space settable using chmem.
^ permalink raw reply
* Re: And another question
From: Tomi Manninen @ 2002-12-12 21:14 UTC (permalink / raw)
To: Linux Hams mailing list
In-Reply-To: <Pine.LNX.4.44.0212121315220.27325-100000@njord.mvw.net>
On Thu, 12 Dec 2002, Michael Willems wrote:
> The first time, instead of a ping (ICMP echo request), my node send a
> packet "from VA3MVW to QST". That results in no replies, so in the shell I
> see "no route to host".
These are ARP packets (Address Resolution Protocol, mapping IP-numbers to
hardware addresses ie. callsigns).
Chances are your ARP timings are too aggressive, they usually are by
default. This causes it to time out and report "no route" to you.
> If I ping again immediately, it DOES send the echo request, and gets back
> an echo ack from the other side, and all is OK< the ping works.
It would seem that the other system does indeed reply to the ARP query
while you are not watching anymore but not in time for the first ping to
succeed. The second time it's cached so everything works.
Two options. First, set up a static ARP entry. This is practical if your
neighbors are very few and static ie. don't change things like their
callsign-ssid's very often. The syntax is something like this:
arp -H ax25 -i <ifname> -s <ipaddr> <callsign>
Second option is to tweak the timings. I prefer this and have this in my
startup script:
# ARP timings
#
PROCPATH=/proc/sys/net/ipv4/neigh/${IFNAME}
echo 5 > ${PROCPATH}/mcast_solicit # 5 retries
echo 500 > ${PROCPATH}/retrans_time # 5 sec intervals
echo 1800 > ${PROCPATH}/base_reachable_time
For further info, see /usr/src/linux/Documentation/filesystems/proc.txt
under "Network Neighbor handling".
--
Tomi Manninen Internet: oh2bns@sral.fi
OH2BNS AX.25: oh2bns@oh2rbi.fin.eu
KP20ME04 Amprnet: oh2bns@oh2rbi.ampr.org
^ permalink raw reply
* Re: rmap15a swappy?
From: Rik van Riel @ 2002-12-12 21:14 UTC (permalink / raw)
To: Sean Neakums; +Cc: linux-mm
In-Reply-To: <6uu1hjruye.fsf@zork.zork.net>
On Thu, 12 Dec 2002, Sean Neakums wrote:
> I just fitted an extra 512M of RAM to my laptop, and though there is
> currently about 400M free, it is still hitting swap. I seem to recall
> that older rmaps generally only started to page stuff out when there
> was no more memory free. (My recollection may be faulty, though.)
Indeed, the older rmaps swapped later. However, swapping
a little bit earlier turns out to be faster for almost all
workloads.
Having said that, for some reason rmap15a is sometimes
swapping a lot too early. This is something I still have
to fix...
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://guru.conectiva.com/
Current spamtrap: <a href=mailto:"october@surriel.com">october@surriel.com</a>
--
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/
^ permalink raw reply
* Re: [PATCH] s390 (8/8): export sys_wait4.
From: Roberto Nibali @ 2002-12-12 21:19 UTC (permalink / raw)
To: Pete Zaitcev; +Cc: linux-kernel
In-Reply-To: <20021212142645.A2998@devserv.devel.redhat.com>
Pete Zaitcev wrote:
>>+EXPORT_SYMBOL(sys_wait4);
>
> Martin, hold on just a second. Last I checked, sys_wait4 was
> used ONLY by a moronic code in ipvs, _and_ there was a comment
> by the author above it "we are too lazy to do it properly".
> Do you have a better reason to export it?
Guess I'm the malefactor this time since I've sent this patch to Martin
after some email exchanges with a guy that wanted LVS to work on a s390.
I reckon I will fix the said moronic code to use a syscall wrapper for
sys_wait4() so we don't step on anyone's toes.
Regards,
Roberto Nibali, ratz
--
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc
^ permalink raw reply
* PROBLEM: 2.4.x hanging in CPU init(?) and memory size strangeness
From: Johnny Teveßen @ 2002-12-12 21:19 UTC (permalink / raw)
To: linux-kernel
(According to REPORTING-BUGS, although I'm not sure whether it's
a bug or not or what is happening at all)
Dear core developers,
I just experienced something rather strange with a 2.4.19pre8 kernel
(yes, 2.4.20 is installed but I didn't update all dependent modules
yet and since I wasn't able to find something about this in a
Changelog, it's probably the same effect with 2.4.20):
WindowsXP running, reset, LILO, boot to 2.4.19pre8 with "mem=nopentium"
set. CPU is:
vendor_id : AuthenticAMD
cpu family : 6
model : 8
model name : AMD Athlon(tm) XP 2200+
stepping : 0
cpu MHz : 1794.951
Well, for the first time (I've been using this kernel for quite
a while now), Linux hung on bootup, somewhere within CPU initialization,
I think (see below). This was reproducable with several hard-resets -
Always the same. When I physically switched off power, waited some
seconds and restarted my hardware from-scratch, Linux booted again.
Please note that while the CPU (or whatever) was in this special
state, even WindowsXP wouldn't boot anymore. According to
motherboard diagnostics (Epox 8K7A+), CPU temperature was always
around 45, 46 degrees C. All fans are working, no OC or similar dirt.
Here's my dmesg output after the first successful boot after
the cold-restart:
Memory: 126776k/131008k available (1050k kernel code, 3844k reserved, 272k
data, 212k init, 0k highmem)
Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes)
Inode-cache hash table entries: 8192 (order: 4, 65536 bytes)
Mount-cache hash table entries: 2048 (order: 2, 16384 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 32768 (order: 5, 131072 bytes)
[**Here** is where booting always stopped before]
CPU: Before vendor init, caps: 0183f9ff c1c7f9ff 00000000, vendor = 2
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After vendor init, caps: 0183f9ff c1c7f9ff 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Please note that this kernel only recognized 128MB of memory at the
moment, but both /proc/meminfo and and free(1) state that I
have in fact 256MB installed:
total: used: free: shared: buffers: cached:
Mem: 263147520 258695168 4452352 0 130617344 29917184
Swap: 419446784 31510528 387936256
total used free shared buffers cached
Mem: 256980 252240 4740 0 127692 25024
-/+ buffers/cache: 99524 157456
Swap: 409616 30772 378844
There is a single 256MB brick installed on the board (DDR RAM).
Second question: How is it possible that the kernel only "sees"
128MB but later uses 256MB without problems?
What exactly is happening between initializing the page cache
and "vendor init" that could lead the kernel to quietly halt
within the boot process? I tried to trace it from init/main.c,
but it seems I'm not good enough in this code yet.
kind regards from Cologne/Germany
johannes
Linux aris.dummy.de 2.4.19-pre8 #1 Sam Mai 4 18:10:42 CEST 2002 i686 unknown
Gnu C 3.2
Gnu make 3.80rc2
util-linux 2.11f
mount 2.11g
modutils 2.4.2
e2fsprogs 1.23
reiserfsprogs 3.x.0j
pcmcia-cs 3.1.33
PPP 2.4.0
isdn4k-utils 3.1pre1
Linux C Library 2.2.4
Dynamic linker (ldd) 2.2.4
Linux C++ Library 5.0.0
Procps 2.0.7
Net-tools 1.60
Console-tools 0.3.3
Sh-utils 2.0
Modules Loaded snd-emu10k1 snd-ac97-codec snd-rawmidi snd-seq-device
snd-util-mem snd-hwdep agpgart NVdriver usb-storage snd-pcm-oss snd-pcm
snd-timer snd-mixer-oss snd sound tvmixer soundcore tuner tvaudio msp3400
bttv videodev i2c-algo-bit i2c-core 8139too mii ipt_REJECT ipt_limit
ipt_state ipt_LOG ip_conntrack_ftp iptable_mangle iptable_nat ip_conntrack
iptable_filter ip_tables ipv6 ide-cd ide-scsi scsi_mod cdrom nls_cp437 vfat
fat nls_iso8859-1 ntfs usb-uhci usbcore
^ permalink raw reply
* [LARTC] How to limit bandwidth by port?
From: David Coello @ 2002-12-12 21:11 UTC (permalink / raw)
To: lartc
Hi again
I am making all the test and probes i cann´t imagine but i begin to think
it´s imposible to limit bandwidth by port. Anybody could put me a code
example that makes this please?
Thanks and regards
David Coello
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* how to swap ctrl/caps lock keys for joe?
From: Jerry James Haumberger @ 2002-12-12 21:09 UTC (permalink / raw)
To: linux-newbie
Hi, folks --
Under BasicLinux I've recently installed the joe editor for its
jstar capabilities (which mimic WordStar). The actual DOS WordStar
editor added a small binary to switch your Caps Lock and left
Ctrl keys to make it easier to manipulate the WordStar navigation
and command key combinations with the left small finger. (The
older computer keyboards didn't have two Ctrl keys -- there was
a Ctrl key just to the left of the "a" key that made Ctrl key
combinations easy.) Under Linux, however, one must deal with
key assignments under various shells and other programs that often
change for each of these applications. I have not found in the
joerc configuration file (or anywhere else, yet) where you can
alter the Caps Lock/left Ctrl key assignments to accommodate an
easier usage of joe/jstar.
Has anyone else on the list encountered this need and found a
working solution for the Linux console? I found a solution through
a Google search for joe that works under X, but I'm not using X
on this machine.
Thank you for any help!
----------------------------------------------------------
Jerry... on a 486 DX2-50MHz with 8MB RAM in BasicLinux 1.7
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs
^ permalink raw reply
* Re: PROCESS IMIGRATION
From: venom @ 2002-12-12 21:16 UTC (permalink / raw)
To: Breno; +Cc: Kernel List
In-Reply-To: <000701c2a208$f50e7a40$8be1a7c8@bsb.virtua.com.br>
You could have a loock at:
http://www.openmosix.org
On Thu, 12 Dec 2002, Breno wrote:
> Date: Thu, 12 Dec 2002 16:04:46 -0200
> From: Breno <breno_silva@bandnet.com.br>
> To: Kernel List <linux-kernel@vger.kernel.org>
> Subject: PROCESS IMIGRATION
>
> Hi
>
> I saw something about one project of FreeBSD and this is about imigration of
> processes between two machines.
> The kernel Linux has something about this , or some project like that ?
>
> thanks
> Breno
>
> -
> 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/
>
^ permalink raw reply
* Re: Aic7xxx v6.2.22 and Aic79xx v1.3.0Alpha2 Released
From: Justin T. Gibbs @ 2002-12-12 21:06 UTC (permalink / raw)
To: Doug Ledford, Christoph Hellwig; +Cc: James Bottomley, linux-scsi
In-Reply-To: <20021212202052.GC8842@redhat.com>
> On Wed, Dec 11, 2002 at 06:17:46PM +0000, Christoph Hellwig wrote:
>>
>> Yupp, it currently crashes when I have both compiled in. Dough, any
>> chance you could fix that? A PCI driver is not supposed to stop over
>> already claimed device.
>
> If you've got a test machine, the attached patch would I think fix the
> problem. Let me know if it does in fact work for you and I'll commit it
> to the tree.
I would have to review the aic7xxx driver's probe and attach routine
to see if in the case of aic7xxx_old probing first all is well. If you
could somehow get pci_dev->driver to get set, in the above load order,
aic7xxx would never even have its probe routine called.
--
Justin
^ permalink raw reply
* Re: pci-skeleton duplex check
From: Donald Becker @ 2002-12-12 21:11 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Roger Luethi, netdev, Linux Kernel Mailing List
In-Reply-To: <3DF8F26E.50306@pobox.com>
On Thu, 12 Dec 2002, Jeff Garzik wrote:
> Donald Becker wrote:
> > [[ I don't know why I bother. The people that now control what goes into
> > the kernel would rather put in random patches from other people than
> > accept a correct fix from me. ]]
>
> I'm very interested in applying fixes from you! I am publicly begging
> you to do so, and even CC'ing lkml on my request.
This is very disingenuous statement.
The drivers in the kernel are now heavily modified and have significantly
diverged from my version. Sure, you are fine with having someone else
do the difficult and unrewarding debugging and maintainence work, while
you work on just the latest cool hardware, change the interfaces and are
concerned only with the current kernel version.
I've been actively developing Linux drivers for over a decade, and run
about two dozen mailing lists for specific drivers. I write diagnostic
routines for every released driver. I thoroughly test and frequently
update the driver set I maintain. And since about 2000, my patches were
ignored while the first notice I've have gotten to changes in my drivers
is the bug reports. And the response: "submit a patch to fix those
newly introduced bugs". I've even had patches ignore in favor of people
that wrote "I don't have the NIC, but here is a change".
A good example is the tulip driver. You repeatedly restructured my
driver in the kernel, splitting into different files. It was still 90+%
my code, but the changes made it impossible to track the modification
history. The kernel driver was long-broken with 21143-SYM cards, but no
one took the responsibility for fixing it.
It's easy to make the first few patches, when you don't have to deal
with reversion testing, many different models, and have an unlimited
sandbox where it doesn't matter if a specific release works or not. But
it takes a huge of work to keep a stable, tracable driver development
process that works with many different kernel versions and hardware
environments.
--
Donald Becker becker@scyld.com
Scyld Computing Corporation http://www.scyld.com
410 Severn Ave. Suite 210 Scyld Beowulf cluster system
Annapolis MD 21403 410-990-9993
^ permalink raw reply
* Re: [PATCH] cs46xx some few corrections
From: Benny Sjostrand @ 2002-12-12 21:00 UTC (permalink / raw)
To: Friedrich Ewaldt; +Cc: alsa-devel
In-Reply-To: <3DF89C1A.9020205@gmx.de>
> As Cirrus doesn't help in the moment, do you have an idea why I managed
> to get perfect sounding SPDIF input (after switching off/on the input 3
> times or so) with 0.9.0rc6 and why I don't get undistorted sound with
> cvs+latest patch? Could you see what loading the win driver before
> booting into linux changes on the card if I would send some proc/asound/
> dumps?
> Thanks!
You right, it must possible to get it that good as it was
in rc6. I'll will investigate in on this.
/Benny
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: Pinning kernel memory
From: Thomas Schlichter @ 2002-12-12 21:04 UTC (permalink / raw)
To: Rik van Riel; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.50L.0212121814450.17748-100000@imladris.surriel.com>
Thanks, Oliver Neukum mailed me a similar answer, too.
So it looks as my problem was an other one, but setting the pages reserved
solved it.
The problem was that I remapped these kernel pages into user space and
accessing this remapped memory always leaded to a SIGBUS. And since setting
the pages reserved "pins" them, I thought they were swapped out...
I don't know if that is the correct way I do it, and if anyone can tell me how
it should be done I'll be interested...
Thomas Schlichter
P.S.: Here are some of the lines from the code I wrote that should show what I
mean... ;-)
int mem_init_module(void)
{
struct page *page;
~~~ cut ~~~
// allocate mem_size bytes of physical continuous kernel memory
page = alloc_pages( GFP_KERNEL, order );
if( !page )
{
printk( "<1>kernel_mem.o: could not get %d bytes of kernel memory\n",
mem_size );
return -ENOMEM;
}
mem_addr = page_address( page );
// pin the memory
while( page < virt_to_page(mem_addr + mem_size) )
SetPageReserved( page++ );
~~~ cut ~~~
return 0; // initialization successful
}
int mem_mmap( struct file *filp, struct vm_area_struct *vma )
{
unsigned long offset; // byte offset from start address
unsigned long physical; // physical start address
unsigned long vsize; // size in virtual address space
unsigned long psize; // size in physical address space
offset = vma->vm_pgoff << PAGE_SHIFT;
physical = virt_to_bus(mem_addr) + offset;
vsize = vma->vm_end - vma->vm_start;
psize = mem_size - offset;
printk( "<1>kernel_mem.o: mmap offset %lu, physical %#010lx, vsize %lu,
psize %lu\n", offset, physical, vsize, psize );
// virtual range is fully mapped to physical address space ?
if ( vsize > psize )
{
printk("<1>kernel_mem.o: mmap failed as vsize > psize\n");
return -EINVAL;
}
// do the remapping
remap_page_range( vma->vm_start, physical, vsize, vma->vm_page_prot );
// register memory operations to the kernel tables (like file operations)
vma->vm_ops = &mem_vm_ops;
// invoke the vma_open routine (which actually does nothing)
mem_vma_open( vma );
return 0;
}
Am Donnerstag, 12. Dezember 2002 21:15 schrieb Rik van Riel:
> On Thu, 12 Dec 2002, Thomas Schlichter wrote:
> > I want to create a big area of unswappable, physical continuous kernel
> > memory for hardware testing purposes. Currently I allocate the memory
> > using alloc_pages(GFP_KERNEL, order) and after this I pin it using
> > SetPageReserved(page) for each page.
>
> Kernel memory is never swappable, so there is no need to "pin it".
>
>
> Rik
^ permalink raw reply
* Re: Success! TWO questions remain
From: Tomi Manninen @ 2002-12-12 20:54 UTC (permalink / raw)
To: linux-hams
In-Reply-To: <200212120934.49608.n7ipb@koster.seatcp.net>
On Thu, 12 Dec 2002, Ken Koster wrote:
> SSH does do encryption and optionally can do compression as well. From
> the SSH man page " It (ssh) is intended to replace rlogin and rsh, and
> provide secure encrypted communications between two untrusted hosts over an
> insecure network."
SSH at least used to have a cipher option "none" that disables all
encryption. It might require recompiling as the option is typically
disabled to protect people who don't understand what it means...
I have used it many times combined with RSA authentication and compression
and I always felt safe about not breaking the rules here in Finland. Of
course I might have been wrong all the time... :)
--
Tomi Manninen Internet: oh2bns@sral.fi
OH2BNS AX.25: oh2bns@oh2rbi.fin.eu
KP20ME04 Amprnet: oh2bns@oh2rbi.ampr.org
^ permalink raw reply
* Re: Adventure - the answer to what went wrong?
From: Alan Cox @ 2002-12-12 20:52 UTC (permalink / raw)
To: Richard Wallman; +Cc: Linux 8086
In-Reply-To: <200212121911.gBCJB75G012842@eddie.loc>
On Thu, 2002-12-12 at 19:11, Richard Wallman wrote:
> I put forward the theory that it fails because the two strings are not
> in the same 64Kb segment. The reason no-one has found this problem
> before is that so far all of the binaries have been <64Kb in size.
ELKS only supports a max of 64K code / 64K data per app...
Alan
^ permalink raw reply
* playback in multiple period_size?
From: Guilhem Tardy @ 2002-12-12 20:50 UTC (permalink / raw)
To: alsa-devel
Hi all,
I have come to realize that, whenever I drain() on a playback_handle to which a
number of sample non-multiple of the period_size has been written, my
application waits for several seconds to finally recover with an error EIO.
Is the driver supposed to play audio if less than period_size is present in the
buffer?
Is the application supposed to always add silence at the end to ensure that a
multiple of period_size has been written?
Thanks,
Guilhem.
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: 2.5.51 nanosleep fails
From: Marco d'Itri @ 2002-12-12 20:57 UTC (permalink / raw)
To: Jim Houston, julie.n.fleischer; +Cc: linux-kernel
In-Reply-To: <3DF7A890.A688AF54@attbi.com>
On Dec 11, Jim Houston <jim.houston@attbi.com> wrote:
>I was able to reproduce this issue. It happens on all the
>kernels I tried including a stock Redhat kernel. This is just
>an idiosyncrasy of strace. In this case both the strace and
No, it is not. It does not happen with 2.4.x kernel and probably did not
happen with 2.5.50.
It *does* happen with 2.5.51 even when strace is not used:
md@wonderland:~$LANG= tail -f /var/log/uucp/Log
[...]
uucico bofh - (2002-12-12 21:50:27.54 4484) Call complete (4 seconds 2336 bytes 584 bps)
[2]+ Stopped LANG= tail -f /var/log/uucp/Log
md@wonderland:~$ fg
LANG= tail -f /var/log/uucp/Log
tail: cannot read realtime clock: Bad address
[Exit 1]
md@wonderland:~$
--
ciao,
Marco
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Vojtech Pavlik @ 2002-12-12 20:56 UTC (permalink / raw)
To: Mark Mielke; +Cc: Terje Eggestad, H. Peter Anvin, linux-kernel, Dave Jones
In-Reply-To: <20021212203646.GA14228@mark.mielke.cc>
On Thu, Dec 12, 2002 at 03:36:46PM -0500, Mark Mielke wrote:
> On Thu, Dec 12, 2002 at 10:42:56AM +0100, Terje Eggestad wrote:
> > On ons, 2002-12-11 at 19:50, H. Peter Anvin wrote:
> > > Terje Eggestad wrote:
> > > > PS: rdtsc on P4 is also painfully slow!!!
> > > Now that's just braindead...
> > It takes about 11 cycles on athlon, 34 on PII, and a whooping 84 on P4.
> > For a simple op like that, even 11 is a lot... Really makes you wonder.
>
> Some of this discussion is a little bit unfair. My understanding of what
> Intel has done with the P4, is create an architecture that allows for
> higher clock rates. Sure the P4 might take 84, vs PII 34, but how many
> PII 2.4 Ghz machines have you ever seen on the market?
>
> Certainly, some of their decisions seem to be a little odd on the surface.
>
> That doesn't mean the situation is black and white.
Assume a 1GHz P-III. 34 clocks @ 1GHz = 34 ns. 84 clocks @ 2.4 GHz = 35 ns.
That's actually slower. Fortunately the P4 isn't this bad on all
instructions.
--
Vojtech Pavlik
SuSE Labs
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: J.A. Magallon @ 2002-12-12 20:56 UTC (permalink / raw)
To: Mark Mielke; +Cc: Terje Eggestad, H. Peter Anvin, linux-kernel, Dave Jones
In-Reply-To: <20021212203646.GA14228@mark.mielke.cc>
On 2002.12.12 Mark Mielke wrote:
>On Thu, Dec 12, 2002 at 10:42:56AM +0100, Terje Eggestad wrote:
>> On ons, 2002-12-11 at 19:50, H. Peter Anvin wrote:
>> > Terje Eggestad wrote:
>> > > PS: rdtsc on P4 is also painfully slow!!!
>> > Now that's just braindead...
>> It takes about 11 cycles on athlon, 34 on PII, and a whooping 84 on P4.
>> For a simple op like that, even 11 is a lot... Really makes you wonder.
>
>Some of this discussion is a little bit unfair. My understanding of what
>Intel has done with the P4, is create an architecture that allows for
>higher clock rates. Sure the P4 might take 84, vs PII 34, but how many
>PII 2.4 Ghz machines have you ever seen on the market?
>
>Certainly, some of their decisions seem to be a little odd on the surface.
>
>That doesn't mean the situation is black and white.
>
No. The situation is just black. Each day Intel processors are a bigger
pile of crap and less intelligent, but MHz compensate for the average
office user. Think of what could a P4 do if the same effort put on
Hz was put on getting cheap a cache of 4Mb or 8Mb like MIPSes have. Or
closer, 1Mb like G4s.
If syscalls take 300% time but processor is also 300% faster 'nobody
notices'.
--
J.A. Magallon <jamagallon@able.es> \ Software is like sex:
werewolf.able.es \ It's better when it's free
Mandrake Linux release 9.1 (Cooker) for i586
Linux 2.4.20-jam1 (gcc 3.2 (Mandrake Linux 9.1 3.2-4mdk))
^ permalink raw reply
* Re: 2.5.51 breaks ALSA AWE32
From: Kai Germaschewski @ 2002-12-12 20:55 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: John Bradford, perex, linux-kernel
In-Reply-To: <20021212205206.GA11836@mars.ravnborg.org>
On Thu, 12 Dec 2002, Sam Ravnborg wrote:
> One detail when looking at the patch:
>
> > ===== sound/synth/emux/Makefile 1.4 vs edited =====
> > --- 1.4/sound/synth/emux/Makefile Tue Jun 18 04:16:20 2002
> > +++ edited/sound/synth/emux/Makefile Thu Dec 12 14:20:08 2002
> > @@ -5,16 +5,11 @@
> >
> > export-objs := emux.o
> >
> > -snd-emux-synth-objs := emux.o emux_synth.o emux_seq.o emux_nrpn.o \
> > - emux_effect.o emux_proc.o soundfont.o
> > -ifeq ($(CONFIG_SND_SEQUENCER_OSS),y)
> > - snd-emux-synth-objs += emux_oss.o
> > -endif
> > +snd-emux-synth-y := emux.o emux_synth.o emux_seq.o emux_nrpn.o \
> > + emux_effect.o emux_proc.o soundfont.o
> > +snd-emux-synth-$(CONFIG_SND_SEQUENCER_OSS) += emux_oss.o
>
> snd-emux-synth-objs := $(snd-emux-synth-y)
Nope, kbuild does that for you ;)
(And yes, lots of places still do it manually, but it's not necessary
anymore).
--Kai
^ permalink raw reply
* Re: 2.5.51 breaks ALSA AWE32
From: Sam Ravnborg @ 2002-12-12 20:52 UTC (permalink / raw)
To: Kai Germaschewski; +Cc: Sam Ravnborg, John Bradford, perex, linux-kernel
In-Reply-To: <Pine.LNX.4.44.0212121421320.17517-100000@chaos.physics.uiowa.edu>
On tor, dec 12, 2002 at 02:26:26 -0600, Kai Germaschewski wrote:
> > Kai, any ideas how to do this in a better way?
>
> The minimal fix I can think of would be
Looks good - thanks.
One detail when looking at the patch:
> ===== sound/synth/emux/Makefile 1.4 vs edited =====
> --- 1.4/sound/synth/emux/Makefile Tue Jun 18 04:16:20 2002
> +++ edited/sound/synth/emux/Makefile Thu Dec 12 14:20:08 2002
> @@ -5,16 +5,11 @@
>
> export-objs := emux.o
>
> -snd-emux-synth-objs := emux.o emux_synth.o emux_seq.o emux_nrpn.o \
> - emux_effect.o emux_proc.o soundfont.o
> -ifeq ($(CONFIG_SND_SEQUENCER_OSS),y)
> - snd-emux-synth-objs += emux_oss.o
> -endif
> +snd-emux-synth-y := emux.o emux_synth.o emux_seq.o emux_nrpn.o \
> + emux_effect.o emux_proc.o soundfont.o
> +snd-emux-synth-$(CONFIG_SND_SEQUENCER_OSS) += emux_oss.o
snd-emux-synth-objs := $(snd-emux-synth-y)
>
> -# Toplevel Module Dependency
> -ifeq ($(subst m,y,$(CONFIG_SND_SEQUENCER)),y)
> - obj-$(CONFIG_SND_SBAWE) += snd-emux-synth.o
> - obj-$(CONFIG_SND_EMU10K1) += snd-emux-synth.o
> -endif
> +obj-$(CONFIG_SND_SBAWE) += snd-emux-synth.o
> +obj-$(CONFIG_SND_EMU10K1) += snd-emux-synth.o
>
> include $(TOPDIR)/Rules.make
>
> However, synth/Makefile still has the ugly ifdef in there, which wouldn't
> be necessary if we entered synth/ just when CONFIG_SND_SEQUENCER is set.
> It looks like more generic routines are in synth/ (util-mem), though,
> which IMO shouldn't be there, but rather in some lib/ or whatever dir. So
> there's the opportunity for further cleanup, but I'll leave that to the
> ALSA people. Anybody care for testing the second patch above?
>
> --Kai
>
^ permalink raw reply
* Re: Adventure - the answer to what went wrong?
From: Dan Olson @ 2002-12-12 20:41 UTC (permalink / raw)
To: Linux 8086
In-Reply-To: <1039724964.1821.28.camel@cool>
> > Also, the file size is 84k, but that doesn't mean that the code segment is
> > going to be more than 64k, does it? Does the whole file get loaded into
> > memory and executed, or can there be other "stuff" in that file besides
> > executable code that may not get loaded into the code segment? I haven't
> > messed with this stuff in a while, so I don't remember :)
> >
> > Dan
>
> It is ok for a file to be bigger than 64K since initialized data exist
> in the file along with the code.
>
> Harry
That's what I was thinking, just haven't done any x86 asm for a while.
Dan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
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.