Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

А что это за технология?
Касательно VM - до 2.6 у линукса была менее эффективное управление памятью, чем в BSD или Windows NT.

Shadow (22.04.2006 18:02:10)

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

Ну, да, зато в ms сидят не идиоты!

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

нихрена себе
так на линуса наехать
и где - на лоре
за это убивать надо

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

ну наехал и наехал
собака лает, караван идет -)

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

зачем так резко на бсдю то? правое дело ребята делают =) в отличии от линукса сдесь все упорядоченнее как-то, небольшая профессиональная команда разработчиков ИМХО на сервер тока бсдю

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

Остапа понесло?

bbk123 (22.04.2006 18:08:22)

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

> Ну, да, зато в ms сидят не идиоты!

В MC сидят отнюдь не идиоты.

lenin (22.04.2006 18:09:31)

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

> А что это за технология?

http://www.freebsd.org/cgi/man.cgi?query=zero_copy

bbk123 (22.04.2006 18:10:05)

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

>>>до 2.6 у линукса была менее эффективное управление памятью

А как оценивается эффективность управления памяти? Потому что в письме Торвальдс заявил, что бенчмарки не дают оценку real-life performance. Так что может быть на тестах _кажущаяся_ эффективность BSD и NT выше.

geekkoo (22.04.2006 18:14:48)

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

А давайте по этому поводу организуем новый праздничный флейм...

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

Не, фича конечно полезная. Но в реализации ахенно скользкая. Заради выгибона ее вкрячивать - тока себе вредить. Без нее хрен скока времени жили и дальше будем, я в этом отношении Линуса понимаю.

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

Ваша хвалёная БЗДа на тестах показавала худшие результаты при сравнетии с тем же линуксом и соляркой. Так что в биоректор вашу БДЗу!

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

Не надо провокационных заголовков.
Автор забыл написать, что Торвальдс добавил

On Thu, 20 Apr 2006, Linus Torvalds wrote:
>
> I claim that Mach people (and apparently FreeBSD) are incompetent idiots.

I also claim that Slashdot people usually are smelly and eat their
boogers, and have an IQ slightly lower than my daughters pet hamster
(that's "hamster" without a "p", btw, for any slashdot posters out
there. Try to follow me, ok?).

Furthermore, I claim that anybody that hasn't noticed by now that I'm an
opinionated bastard, and that "impolite" is my middle name, is lacking a
few clues.

Finally, it's clear that I'm not only the smartest person around, I'm also incredibly good-looking, and that my infallible charm is also second only to my becoming modesty.

So there. Just to clarify.



Так что автор как раз попадает под первое определение читателей slashdot.

Продолжаем по сути вопроса: Торвальдс утверждает, что cow механизм, сделанный во freebsd плох, и это верно по следующей причине:
повторный page fault приведет к заметному падению производительности, однако стоит заметить, что для задач, где не требуется изменение, а только анализ потока, т.е. где повторного page fault не будет, этот метод дает заметное увеличение производительности.

Во freebsd таким образом сделан receivin zero copy, т.е. данные копируются из сетевой карты в память компьютера, а затем хитрым образом подставляются в VFS cache или userspace pages, при этом в обязательном пордке происходит как минимум 1 TLB flush, а если затем пользователь пишет в эти страницы, то это генерирует page fault, обработка которого занимает _чрезвычайно_ много времени. Это-то и не нравится Торвальдсу и всем нормальным людям.

Впрочем, во freebsd это практически не используется.

rtc (22.04.2006 18:24:16)

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

Молодец Линус. Наконец то хоть кто то сказал правду о бздунах.

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

>Ваша хвалёная БЗДа на тестах показавала худшие результаты при сравнетии с тем же линуксом и соляркой. Так что в биоректор вашу БДЗу!

Ага. Любую систему можно так "настролить", что она не будет работать.

Афффторам печально известного теста это вполне удалось.

stellar (22.04.2006 18:25:13)

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

Все равно, Линусу поспокойнее нужно быть, если он действителдьно так ругался ;)

GladAlex (22.04.2006 18:25:13)

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

А что праздник по поводу субжа? ну что за народ...

Begemoth (22.04.2006 18:25:23)

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

> Касательно VM - до 2.6 у линукса была менее эффективное управление памятью, чем в BSD или Windows NT.

Извини, но в виндах самый отстойный VM какой я когда-либо тестил.

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

А вот интересно, я не слежу за тем что куда Линус пишет. Он всегда такие эпитеты роздает или его тут сильно задело? Он вообще какую-то реальную роль в розработке ядра играет? Если завтра он с собой покончит, как это повлияет на процесс розработки ядра? Является ли он одним из заслуженно самых уважаемых розработчиков или так, нечно типа знамени и давно уже никому особо неинтересен?

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

>>Он всегда такие эпитеты роздает или его тут сильно задело?

Выше же rtc процитировал:

I claim that anybody that hasn't noticed by now that I'm an
opinionated bastard, and that "impolite" is my middle name, is lacking a few clues.

geekkoo (22.04.2006 18:33:03)

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

>А вот интересно, я не слежу за тем что куда Линус пишет. Он всегда такие эпитеты роздает или его тут сильно задело? Он вообще какую-то реальную роль в розработке ядра играет? Если завтра он с собой покончит, как это повлияет на процесс розработки ядра? Является ли он одним из заслуженно самых уважаемых розработчиков или так, нечно типа знамени и давно уже никому особо неинтересен?

В первую очередь он координатор, сам практически ничего не пишет, но обладет очень обширными познаниями во многих областях, поэтому он комментирует и код VM, и архитектурно-специфические вещи вроде барьеров в alpha (впрочем, про эту несчастную alpha уже легенды слагать пора).

Если завтра он уйдет, то разработка продолжится, т.к. на его место быстро найдут другого, может быть менее харизматичного, лидера.

rtc (22.04.2006 18:33:51)

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

> А как оценивается эффективность управления памяти?
Задумчивой реакцией на загрузку больших программ с кучей либ в память.

2.4 даже со свопом, настроенным так, чтобы туда, как в BSD и виндовс, выкидывалось всё неиспользуемое, всё равно задумывался при запуске программ не на чистом xlib.

Я крутил его и так, и эдак - во фре четвёртой как-то пошустрее всё реагировало, я сносил линукс. 2.6 - это уже было нормально, а тем временем во фре стабильной не хватало функционала - и я снёс фрю.

Shadow (22.04.2006 18:36:40)

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

> отличии от линукса сдесь все упорядоченнее как-то, небольшая
> профессиональная команда разработчиков

ну не знаю, сравни например FreeBSD реализация open:
int
kern_open(struct thread *td, char *path, enum uio_seg pathseg, int flags,
int mode)
{
struct proc *p = td->td_proc;
struct filedesc *fdp = p->p_fd;
struct file *fp;
struct vnode *vp;
struct vattr vat;
struct mount *mp;
int cmode;
struct file *nfp;
int type, indx, error;
struct flock lf;
struct nameidata nd;
int vfslocked;

AUDIT_ARG(fflags, flags);
AUDIT_ARG(mode, mode);
if ((flags & O_ACCMODE) == O_ACCMODE)
return (EINVAL);
flags = FFLAGS(flags);
error = falloc(td, &nfp, &indx);
if (error)
return (error);
/* An extra reference on `nfp' has been held for us by falloc(). */
fp = nfp;
cmode = ((mode &~ fdp->fd_cmask) & ALLPERMS) &~ S_ISTXT;
NDINIT(&nd, LOOKUP, FOLLOW | AUDITVNODE1 | MPSAFE, pathseg, path, td);
td->td_dupfd = -1; /* XXX check for fdopen */
error = vn_open(&nd, &flags, cmode, indx);
if (error) {
/*
* If the vn_open replaced the method vector, something
* wonderous happened deep below and we just pass it up
* pretending we know what we do.
*/
if (error == ENXIO && fp->f_ops != &badfileops) {
fdrop(fp, td);
td->td_retval[0] = indx;
return (0);
}

/*
* release our own reference
*/
fdrop(fp, td);

/*
* handle special fdopen() case. bleh. dupfdopen() is
* responsible for dropping the old contents of ofiles[indx]
* if it succeeds.
*/
if ((error == ENODEV || error == ENXIO) &&
td->td_dupfd >= 0 && /* XXX from fdopen */
(error =
dupfdopen(td, fdp, indx, td->td_dupfd, flags, error)) == 0) {
td->td_retval[0] = indx;
return (0);
}
/*
* Clean up the descriptor, but only if another thread hadn't
* replaced or closed it.
*/
fdclose(fdp, fp, indx, td);

if (error == ERESTART)
error = EINTR;
return (error);
}
td->td_dupfd = 0;
vfslocked = NDHASGIANT(&nd);
NDFREE(&nd, NDF_ONLY_PNBUF);
vp = nd.ni_vp;

/*
* There should be 2 references on the file, one from the descriptor
* table, and one for us.
*
* Handle the case where someone closed the file (via its file
* descriptor) while we were blocked. The end result should look
* like opening the file succeeded but it was immediately closed.
* We call vn_close() manually because we haven't yet hooked up
* the various 'struct file' fields.
*/
FILEDESC_LOCK(fdp);
FILE_LOCK(fp);
if (fp->f_count == 1) {
mp = vp->v_mount;
KASSERT(fdp->fd_ofiles[indx] != fp,
("Open file descriptor lost all refs"));
FILE_UNLOCK(fp);
FILEDESC_UNLOCK(fdp);
VOP_UNLOCK(vp, 0, td);
vn_close(vp, flags & FMASK, fp->f_cred, td);
VFS_UNLOCK_GIANT(vfslocked);
fdrop(fp, td);
td->td_retval[0] = indx;
return (0);
}
fp->f_vnode = vp;
if (fp->f_data == NULL)
fp->f_data = vp;
fp->f_flag = flags & FMASK;
if (fp->f_ops == &badfileops)
fp->f_ops = &vnops;
fp->f_seqcount = 1;
fp->f_type = (vp->v_type == VFIFO ? DTYPE_FIFO : DTYPE_VNODE);
FILE_UNLOCK(fp);
FILEDESC_UNLOCK(fdp);

VOP_UNLOCK(vp, 0, td);
if (flags & (O_EXLOCK | O_SHLOCK)) {
lf.l_whence = SEEK_SET;
lf.l_start = 0;
lf.l_len = 0;
if (flags & O_EXLOCK)
lf.l_type = F_WRLCK;
else
lf.l_type = F_RDLCK;
type = F_FLOCK;
if ((flags & FNONBLOCK) == 0)
type |= F_WAIT;
if ((error = VOP_ADVLOCK(vp, (caddr_t)fp, F_SETLK, &lf,
type)) != 0)
goto bad;
fp->f_flag |= FHASLOCK;
}
if (flags & O_TRUNC) {
if ((error = vn_start_write(vp, &mp, V_WAIT | PCATCH)) != 0)
goto bad;
VOP_LEASE(vp, td, td->td_ucred, LEASE_WRITE);
VATTR_NULL(&vat);
vat.va_size = 0;
vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, td);
#ifdef MAC
error = mac_check_vnode_write(td->td_ucred, fp->f_cred, vp);
if (error == 0)
#endif
error = VOP_SETATTR(vp, &vat, td->td_ucred, td);
VOP_UNLOCK(vp, 0, td);
vn_finished_write(mp);
if (error)
goto bad;
}
VFS_UNLOCK_GIANT(vfslocked);
/*
* Release our private reference, leaving the one associated with
* the descriptor table intact.
*/
fdrop(fp, td);
td->td_retval[0] = indx;
return (0);
bad:
VFS_UNLOCK_GIANT(vfslocked);
fdclose(fdp, fp, indx, td);
fdrop(fp, td);
return (error);
}


-------------------------------------------

и линукс:
long do_sys_open(int dfd, const char __user *filename, int flags, int mode)
{
char *tmp = getname(filename);
int fd = PTR_ERR(tmp);

if (!IS_ERR(tmp)) {
fd = get_unused_fd();
if (fd >= 0) {
struct file *f = do_filp_open(dfd, tmp, flags, mode);
if (IS_ERR(f)) {
put_unused_fd(fd);
fd = PTR_ERR(f);
} else {
fsnotify_open(f->f_dentry);
fd_install(fd, f);
}
}
putname(tmp);
}
return fd;
}

что понятнее и проще исправить и что похоже на написанное профессионалом?

fghj (22.04.2006 18:40:13)

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

Так тема просто довольно провакационная. С одной стороны - великий Линус расставил все точки над i. С другой - странный, несдержанный и некомпетентный Лисус бездарно наехал на розработчиков FreeBSD. С третьей - мало кто в предметной области разбирается. Плюс погода хорошая. Не, точно надо флейм провоцировать.

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

Я уже не говорю о том что тема реально интересной может оказаться. Так ЛОР ЛОРом не будет просто.

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

У них разное количество аргументов. Как их можно сравнивать?

bbk123 (22.04.2006 18:49:25)

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

Угу. А Тео Де Радт сообщает, что линукс - мусор, и пользователи просто привязались к этой системе...

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

Швед дело говорит: бздуны только бздеть могут, да код отдавать кому ни попадя за так, а писать его грамотно они не умеют.

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

Надо сделать так, чтобы они застряли в одном лифте :-))

bbk123 (22.04.2006 18:52:22)

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

Он ещё ответит за свои злодеяния.

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

>ero copy sockets code first appeared in FreeBSD 5.0, although it has been in existence in patch form since at least mid-1999.

Вещь давно известная и практически не используемая, я вообще не поняла, ну не хочет он ее добавлять, ну и хер с ним, зачем это выносить на всеобщее обсуждение?

Sun-ch (22.04.2006 18:57:55)

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

Линус прав, теоритечески "Playing games with VM" это хорошо, но т.к. TLB сбрасывается только полностью то это "BAD".

всвязи с ростом объёмов памяти и адресного пространства логично появление команд для управления TLB раз уж его кривую архитектуру у интела уже поздно менять.

blind (22.04.2006 19:01:34)

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

По моему один горячий финский парень в конец зарвался... Но ничего, есть кому ядро разрабатывать. :)

atrus (22.04.2006 19:01:35)

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

А ты do_filp_open покажи. И столько if else использовать, имхо, не профессионально. А вот линейный код с отвалами при обломах выглядит лучше даже если он не 20 строчек.

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

>>ero copy sockets code first appeared in FreeBSD 5.0, although it has been in existence in patch form since at least mid-1999.

>Вещь давно известная и практически не используемая, я вообще не поняла, ну не хочет он ее добавлять, ну и хер с ним, зачем это выносить на всеобщее обсуждение?

Вопрос изначально зашел о механизмах работы новых системных вызовов splice() и tee(), и последующей реализации vmsplice(), и кто-то заметил, что этот механизм можно было бы сделать похожим на freebsd ZERO_COPY_SOCKET, используя COW для страниц, которые обрабатываются в ядре, на что Торвальдс и сказал, что такой механизм - полный отстой.

>Sun-ch # (*) (22.04.2006 18:57:55)

rtc (22.04.2006 19:04:27)

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

>Линус прав, теоритечески "Playing games with VM" это хорошо, но т.к. TLB сбрасывается только полностью то это "BAD".

>всвязи с ростом объёмов памяти и адресного пространства логично появление команд для управления TLB раз уж его кривую архитектуру у интела уже поздно менять.

Это только в i386 TLB целиком сбрасывается.

>blind * (*) (22.04.2006 19:01:34)

rtc (22.04.2006 19:05:20)

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

> вообще не поняла

саныч...ты эта...выдыхай. А то вошёл в роль...как бы чего не вышло (или не вошло)

geek (22.04.2006 19:06:38)

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

и каким магическим образом процессор понимает что конкретно поменялось в TLB?

blind (22.04.2006 19:09:14)

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

Слава Линусу!

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

Идиоты в M$ отнюдь не сидят. Они лежат в мавзолее.

eXOR (22.04.2006 19:19:49)

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

>саныч...ты эта...выдыхай. А то вошёл в роль...как бы чего не вышло (или не вошло)

А что Саша мальчик? В смысле, мужского пола?

ansi (22.04.2006 19:27:48)

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

>А что Саша мальчик? В смысле, мужского пола?

была. или был. Я уже не знаю как правильно :)

geek (22.04.2006 19:32:43)

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

В топике есть большой смысл. Например, кто-то решит изучить вопрос, в котором не разбирался перед тем, как осуждать/хвалить Линуса за выпад.

Я вот успел узнать по теме Zero Copy Socket, что есть ограничения по использованию. Они касаются и размера пакета данных (размер MTU должен равен размеру страницы), и выравнивания (alignment). Базируясь на мнении Линуса и других комментаторов (но пока не на своем), я понял, что эта технология плохо масштабируется (масштабируемость в смысле многопроцессорных систем). А вместо всего этого Линус предложил vmsplice().

Вот тут Линус этот вопрос вкратце освещает:

http://lkml.org/lkml/2006/4/19/237

Zubok (22.04.2006 19:33:53)

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

>> об использовании техники copy-on-write вообще

Ну написал...

Ща толпа анонимусов (и не только) подумает, что COW вообще зло, которое надо искоренять :)

sergej (22.04.2006 19:34:43)

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

>Я вот успел узнать по теме Zero Copy Socket, что есть ограничения по использованию. Они касаются и размера пакета данных (размер MTU должен равен размеру страницы), и выравнивания (alignment).

Вовсе не обязательно, это просто _очень_ удобно, но существуют и другие схемы. Смотерть в сторону sendfile(), который хоть и работает со страницами, но MTU при этом может быть любым. Так же и для приема.

>Базируясь на мнении Линуса и других комментаторов (но пока не на своем), я понял, что эта технология плохо масштабируется (масштабируемость в смысле многопроцессорных систем). А вместо всего этого Линус предложил vmsplice().

Это именно freebsd ZERO_COPY_SOCKET плохо масштабируется, в Linux вообще нет receiving zero-copy support в официальном ядре, только сторонние патчи. Точнее даже не конкретно реализация freebsd, а побоные игры с VM.

>Zubok ** (*) (22.04.2006 19:33:53)

rtc (22.04.2006 19:42:39)

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

Все таки какой Линус храбрый, умный. Молодец он.

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

>Это именно freebsd ZERO_COPY_SOCKET плохо масштабируется

Так я же про нее и говорю! "Эта технология..." (имелась с виду ZERO_COPY_SOCKET)

Zubok (22.04.2006 19:44:52)

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

>в Linux вообще нет receiving zero-copy support в официальном ядре, только сторонние патчи. Точнее даже не конкретно реализация freebsd, а побоные игры с VM.

Насколько я понял, Линус об этих "играх" заговорил только недавно. Во всяком случае эти разговоры о vmsplice() на lkml датируются апрелем этого года (апрельские тезисы Линуса? :). Ну а так как Линус носом от этих игр с VM нос не ворочает, как от ZERO_COPY_SOCKET, то это возможно когда-нибудь этот vmsplice() сможет войти в ядро официально (когда наиграются всласть) :)

Zubok (22.04.2006 19:49:43)

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

vmsplice() будет в 2.6.17, splice() и tee() уже в дереве. Но для receiving zero-copy support этого еще не достаточно, передающая же часть (sendfile()) будет переведена на splice().

rtc (22.04.2006 20:04:33)

Re: Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

>Я вот успел узнать по теме Zero Copy Socket, что есть ограничения по использованию. Они касаются и размера пакета данных (размер MTU должен равен размеру страницы), и выравнивания (alignment).

>Вовсе не обязательно, это просто _очень_ удобно, но существуют и другие схемы.

Тогда я не понимаю, о чем речь идет в этих предложениях (по ZERO_COPY_SOCKET):

Для передачи:

The data written to the socket, though, must be at least a page in size and page aligned in order to be mapped into the kernel. If it does not meet the page size and alignment constraints, it will be copied into the kernel, as is normally the case with socket I/O.

Для приема:

Additionally, in order for zero copy receive to work, packet payloads must be at least a page in size and page aligned.

Zubok (22.04.2006 20:04:58)