Re: [devel] E: incoming x86_64 reject: sbcl-0.9.17-alt1

Re: [devel] E: incoming x86_64 reject: sbcl-0.9.17-alt1

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 551 bytes --]

On Mon, Oct 09, 2006 at 11:35:45PM +0300, Vadim V. Zhytnikov wrote:
> Upravdom Team Robot ?????:
> > Dear Vadim V. Zhytnikov !
> > The sbcl-0.9.17-alt1 package has been rejected from incoming for x86_64
> > architecture.
> 
> > mmap: Cannot allocate memory
> > ensure_space: failed to validate 8589869056 bytes at 0x1000000000
> > (hint: Try "ulimit -a"; maybe you should increase memory limits.)
> 
> ?? ???, ????? ?? ??????? ??????????? ?????? ??? ?????? ?? x86_64 !

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


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] E: incoming x86_64 reject: sbcl-0.9.17-alt1

[Vadim V. Zhytnikov]

Upravdom Team Robot ?????:
> Dear Vadim V. Zhytnikov !
> The sbcl-0.9.17-alt1 package has been rejected from incoming for x86_64
> architecture.

> mmap: Cannot allocate memory
> ensure_space: failed to validate 8589869056 bytes at 0x1000000000
> (hint: Try "ulimit -a"; maybe you should increase memory limits.)

?? ???, ????? ?? ??????? ??????????? ?????? ??? ?????? ?? x86_64 !

-- 
      Vadim V. Zhytnikov

       <vvzhy@mail.ru>
      <vvzhy@netorn.ru>

Re: [devel] E: incoming x86_64 reject: sbcl-0.9.17-alt1

[Vadim V. Zhytnikov]

Dmitry V. Levin пишет:
> On Mon, Oct 09, 2006 at 11:35:45PM +0300, Vadim V. Zhytnikov wrote:
>> Upravdom Team Robot ?????:
>>> Dear Vadim V. Zhytnikov !
>>> The sbcl-0.9.17-alt1 package has been rejected from incoming for x86_64
>>> architecture.
>>> mmap: Cannot allocate memory
>>> ensure_space: failed to validate 8589869056 bytes at 0x1000000000
>>> (hint: Try "ulimit -a"; maybe you should increase memory limits.)

Прошу прощения за глюк с кодировкой.
По содержанию - сборка нового релиза sbcl на x86_64
требует 8Гб виртуальной памяти.

-- 
      Vadim V. Zhytnikov

       <vvzhy@mail.ru>
      <vvzhy@netorn.ru>

Re: [devel] E: incoming x86_64 reject: sbcl-0.9.17-alt1

[Stanislav Ievlev]

On Tue, Oct 10, 2006 at 08:59:17AM +0300, Vadim V. Zhytnikov wrote:
> Dmitry V. Levin пишет:
> > On Mon, Oct 09, 2006 at 11:35:45PM +0300, Vadim V. Zhytnikov wrote:
> >> Upravdom Team Robot ?????:
> >>> Dear Vadim V. Zhytnikov !
> >>> The sbcl-0.9.17-alt1 package has been rejected from incoming for x86_64
> >>> architecture.
> >>> mmap: Cannot allocate memory
> >>> ensure_space: failed to validate 8589869056 bytes at 0x1000000000
> >>> (hint: Try "ulimit -a"; maybe you should increase memory limits.)
> 
> Прошу прощения за глюк с кодировкой.
> По содержанию - сборка нового релиза sbcl на x86_64
> требует 8Гб виртуальной памяти.
Может быть его пропатчить дабы умерить аппетиты?
Кстати что говорит upstream по этому поводу?

Re: [devel] E: incoming x86_64 reject: sbcl-0.9.17-alt1

[Stanislav Ievlev]

On Tue, Oct 10, 2006 at 10:23:48AM +0300, Vadim V. Zhytnikov wrote:
> Stanislav Ievlev пишет:
> >> По содержанию - сборка нового релиза sbcl на x86_64
> >> требует 8Гб виртуальной памяти.
> > Может быть его пропатчить дабы умерить аппетиты?
> > Кстати что говорит upstream по этому поводу?
> 
> С upstream связываться не пытался, но подозреваю,
> что понимания мы здесь не найдём.
Давайте попробуем. Как я понимаю, sbcl имеет сейчас самое большое community
среди lisp проектов и это community должно быть заинтересовано в качестве
продукта. Мало ли какие где будут стоять лимиты на память.

Re: [devel] E: incoming x86_64 reject: sbcl-0.9.17-alt1

[Damir Shayhutdinov]

10.10.06, Vadim V. Zhytnikov написал(а):
> Stanislav Ievlev пишет:
> >> По содержанию - сборка нового релиза sbcl на x86_64
> >> требует 8Гб виртуальной памяти.
> > Может быть его пропатчить дабы умерить аппетиты?
> > Кстати что говорит upstream по этому поводу?
>
> С upstream связываться не пытался, но подозреваю,
> что понимания мы здесь не найдём.
Он хочет выделить 0x1FFFF0000 байт
Это явно где-то в программе ошибка.

Re: [devel] E: incoming x86_64 reject: sbcl-0.9.17-alt1

[Vadim V. Zhytnikov]

Stanislav Ievlev пишет:
>> По содержанию - сборка нового релиза sbcl на x86_64
>> требует 8Гб виртуальной памяти.
> Может быть его пропатчить дабы умерить аппетиты?
> Кстати что говорит upstream по этому поводу?

С upstream связываться не пытался, но подозреваю,
что понимания мы здесь не найдём.

Патчить можно, но не очень хочется.
Дело не в усилиях а в последствиях.
Поди разберись почему программа сегфолтится
после очередной сборки мусора или попытки
аллоцировать память - upstream виновата или
патчи.

Кстати, а какой ulimit сейчас стоит на x86_64
сборочном сервере?


-- 
      Vadim V. Zhytnikov

       <vvzhy@mail.ru>
      <vvzhy@netorn.ru>

Re: [devel] E: incoming x86_64 reject: sbcl-0.9.17-alt1

[Vadim V. Zhytnikov]

Stanislav Ievlev пишет:
> On Tue, Oct 10, 2006 at 10:23:48AM +0300, Vadim V. Zhytnikov wrote:
>> Stanislav Ievlev пишет:
>>>> По содержанию - сборка нового релиза sbcl на x86_64
>>>> требует 8Гб виртуальной памяти.
>>> Может быть его пропатчить дабы умерить аппетиты?
>>> Кстати что говорит upstream по этому поводу?
>> С upstream связываться не пытался, но подозреваю,
>> что понимания мы здесь не найдём.
> Давайте попробуем. Как я понимаю, sbcl имеет сейчас самое большое community
> среди lisp проектов и это community должно быть заинтересовано в качестве
> продукта. Мало ли какие где будут стоять лимиты на память.
> 

И всё-таки - какие у нас сейчас лимиты?

-- 
      Vadim V. Zhytnikov

       <vvzhy@mail.ru>
      <vvzhy@netorn.ru>

Re: [devel] E: incoming x86_64 reject: sbcl-0.9.17-alt1

[Michael Shigorin]

On Tue, Oct 10, 2006 at 10:45:46AM +0300, Vadim V. Zhytnikov wrote:
> И всё-таки - какие у нас сейчас лимиты?

Что-то около гига вроде было.  Для втягивания в git firefox
подымали, что ли.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] E: incoming x86_64 reject: sbcl-0.9.17-alt1

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 478 bytes --]

On Tue, Oct 10, 2006 at 04:42:04PM +0300, Vadim V. Zhytnikov wrote:
> Зачем вообще устанавливается лимит на виртуальную память
> (ulimit -v) ведь есть же лимит на RSS (ulimit -m)?

Он не работает:

RLIMIT_RSS
      Specifies  the  limit  (in  pages) of the process's resident set
      (the number of virtual pages resident in RAM).  This limit  only
      has  effect in Linux 2.4.x, x < 30, and there only affects calls
      to madvise() specifying MADV_WILLNEED.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] E: incoming x86_64 reject: sbcl-0.9.17-alt1

[Vadim V. Zhytnikov]

Stanislav Ievlev пишет:
>> С upstream связываться не пытался, но подозреваю,
>> что понимания мы здесь не найдём.
> Давайте попробуем. Как я понимаю, sbcl имеет сейчас самое большое community
> среди lisp проектов и это community должно быть заинтересовано в качестве
> продукта. Мало ли какие где будут стоять лимиты на память.

Оказывается существует lazy allocation patch, но его
статус для текущей версии не ясен.  Буду копать
дальше.  Это был бы идеальный вариант.  А без этого патча
sbcl при старте захватывает максимальное количество
виртуальной памяти - такова стратегия унаследованная от cmucl. 
Стараться уменьшить это максимальное значение руками
я не буду, т.к. это существенно урезает функциональность,
особенно на x86_64.

Главное, я не понимаю самой существенной вещи.
Зачем вообще устанавливается лимит на виртуальную память
(ulimit -v) ведь есть же лимит на RSS (ulimit -m)?
Что плохого может случиться если на сборочном сервере
поднять ulimit -v ?  Объясните пожалуйста, а то я просто
не понимаю за что борюсь!

Ну и ещё вопрос.  Сначала я подумал, что sbcl 0.9.17
использует больше виртуальной памяти, чем 0.9.10,
который успешно живет в Сизифе с марта. Это не так -
требования по памяти у этих версии sbcl идентичны.
Но 0.9.10 пересобирался! И maxima-sbcl тоже пересобиралась!
При этом должно было использоваться те самые 8Гб памяти.
Разные сборочные и пересборосные сервера с разными лимитами.


-- 
      Vadim V. Zhytnikov

       <vvzhy@mail.ru>
      <vvzhy@netorn.ru>

Re: [devel] E: incoming x86_64 reject: sbcl-0.9.17-alt1

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 168 bytes --]

On Tue, Oct 10, 2006 at 10:23:48AM +0300, Vadim V. Zhytnikov wrote:
[...]
> Кстати, а какой ulimit сейчас стоит на x86_64
> сборочном сервере?

2G.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] E: incoming x86_64 reject: sbcl-0.9.17-alt1

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 336 bytes --]

On Tue, Oct 10, 2006 at 10:50:32AM +0300, Michael Shigorin wrote:
> On Tue, Oct 10, 2006 at 10:45:46AM +0300, Vadim V. Zhytnikov wrote:
> > И всё-таки - какие у нас сейчас лимиты?
> 
> Что-то около гига вроде было.  Для втягивания в git firefox
> подымали, что ли.

Вадим спрашивал про лимит на сборочном сервере.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] E: incoming x86_64 reject: sbcl-0.9.17-alt1

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 670 bytes --]

On Tue, Oct 10, 2006 at 04:42:04PM +0300, Vadim V. Zhytnikov wrote:
[...]
> Ну и ещё вопрос.  Сначала я подумал, что sbcl 0.9.17
> использует больше виртуальной памяти, чем 0.9.10,
> который успешно живет в Сизифе с марта. Это не так -
> требования по памяти у этих версии sbcl идентичны.
> Но 0.9.10 пересобирался!

Да, на x86-64 вручную.

> И maxima-sbcl тоже пересобиралась!

На x86-64 вручную.

> При этом должно было использоваться те самые 8Гб памяти.

На x86-64 8Гб памяти виртуальной памяти недостаточно.

> Разные сборочные и пересборосные сервера с разными лимитами.

Тестовая пересборка Сизифа на x86-64 ещё не проводилась.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] E: incoming x86_64 reject: sbcl-0.9.17-alt1

[Vadim V. Zhytnikov]

Dmitry V. Levin пишет:
>> Но 0.9.10 пересобирался!
> 
> Да, на x86-64 вручную.
> 
>> И maxima-sbcl тоже пересобиралась!
> 
> На x86-64 вручную.
> 
>> При этом должно было использоваться те самые 8Гб памяти.
> 
> На x86-64 8Гб памяти виртуальной памяти недостаточно.
> 
>> Разные сборочные и пересборосные сервера с разными лимитами.
> 
> Тестовая пересборка Сизифа на x86-64 ещё не проводилась.
> 

Понятно, вся магия оказалась ловкостью рук :-)

К сожалению, мне ничего не остаётся как только
попросить продолжить эту ручную работу, ибо:

- насильно уменьшать максимальный объем памяти на x86_64
считаю бессысленным и вредным.

- lazy allocation patch, когда виртуальная память выделяется
по мере надобности, хотя апстримом и рассматривается, но
сейчас его нет и непонятно когда будет.
В Debian этого патча нет, хотя мантайнером пакета является
именно автор lazy allocation patch.

-- 
      Vadim V. Zhytnikov

       <vvzhy@mail.ru>
      <vvzhy@netorn.ru>

Re: [devel] E: incoming x86_64 reject: sbcl-0.9.17-alt1

[Денис Смирнов]

On Tue, Oct 10, 2006 at 04:42:04PM +0300, Vadim V. Zhytnikov wrote:

 VVZ> Оказывается существует lazy allocation patch, но его
 VVZ> статус для текущей версии не ясен.  Буду копать
 VVZ> дальше.  Это был бы идеальный вариант.  А без этого патча
 VVZ> sbcl при старте захватывает максимальное количество
 VVZ> виртуальной памяти - такова стратегия унаследованная от cmucl. 
 VVZ> Стараться уменьшить это максимальное значение руками
 VVZ> я не буду, т.к. это существенно урезает функциональность,
 VVZ> особенно на x86_64.

Может сделать количество выделяемой им виртуальной памяти конфигурируемым?

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
> +10
Бывает только +1... разве что у тебя такая шиза %)
		-- mike in smoke-room@

Re: [devel] E: incoming x86_64 reject: sbcl-0.9.17-alt1

[Vadim V. Zhytnikov]

Денис Смирнов пишет:
>  VVZ> виртуальной памяти - такова стратегия унаследованная от cmucl. 
>  VVZ> Стараться уменьшить это максимальное значение руками
>  VVZ> я не буду, т.к. это существенно урезает функциональность,
>  VVZ> особенно на x86_64.
> 
> Может сделать количество выделяемой им виртуальной памяти конфигурируемым?
> 

А в этом нет никакого смысла.  Если в момент сборки установить
меньший объем памяти, то полученный образ системы (core)
и будет работать только именно с таким объемом.
В любом члучае получается кастрированная система.

-- 
      Vadim V. Zhytnikov

       <vvzhy@mail.ru>
      <vvzhy@netorn.ru>

Re: [devel] E: incoming x86_64 reject: sbcl-0.9.17-alt1

[Денис Смирнов]

On Tue, Oct 10, 2006 at 11:13:02PM +0300, Vadim V. Zhytnikov wrote:

VVZ> А в этом нет никакого смысла.  Если в момент сборки установить
VVZ> меньший объем памяти, то полученный образ системы (core)
VVZ> и будет работать только именно с таким объемом.
VVZ> В любом члучае получается кастрированная система.

То есть размер выделяемой памяти задается только compile time, и это
невозможно изменить at run time?

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
<aen> DOC_: сейчас весь talk-room -- сплошная фортунка :-) Для пакета
      fortunes-morons.

Re: [devel] E: incoming x86_64 reject: sbcl-0.9.17-alt1

[Vadim V. Zhytnikov]

Денис Смирнов пишет:
> On Tue, Oct 10, 2006 at 11:13:02PM +0300, Vadim V. Zhytnikov wrote:
> 
> VVZ> А в этом нет никакого смысла.  Если в момент сборки установить
> VVZ> меньший объем памяти, то полученный образ системы (core)
> VVZ> и будет работать только именно с таким объемом.
> VVZ> В любом члучае получается кастрированная система.
> 
> То есть размер выделяемой памяти задается только compile time, и это
> невозможно изменить at run time?
> 
Да

-- 
      Vadim V. Zhytnikov

       <vvzhy@mail.ru>
      <vvzhy@netorn.ru>