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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 это практически не используется.

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

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

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

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

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

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

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

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

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

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

Выше же 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.

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

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

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

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

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

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

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

ну не знаю, сравни например 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;
}

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

Так тема просто довольно провакационная. С одной стороны - великий Линус расставил все точки над i. С другой - странный, несдержанный и некомпетентный Лисус бездарно наехал на розработчиков 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.

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

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

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

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

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

>>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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>Я вот успел узнать по теме 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)

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

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

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

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

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

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

>Я вот успел узнать по теме 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.