memory lock (+)

Общая концепция в Linux 2.4 примерно такая (очень упрощенно):

в Linux есть страничный кэш, который состоит из страниц, в которых хранятся данные. У каждой страницы есть счетчик count, который определяет число "пользователей" этой страницы; до тех пор пока счетчик ненулевой данные, связанные со страницей, не могут быть удалены из памяти. В упрощенном представлении счетчик страницы - это число ее отображений в память процессов. paging страницы, как я сказал выше, осуществляется только если счетчик равен 0, т.е. когда страница не имеет ни одного отображения (когда нужно освободить память kswapd, бегает по адресным пространствам всех процессов и делает unmap страниц, уменьшая их count и если count становится равным нулю, то - упрощенно - удаляет страницу из памяти).

mlock запрещает kswapd делать unmap страниц в определенной области данного процесса и создает трансляцию всех страниц области(тем самым устанавливая count как минимум в 1). При fork копируются таблицы страниц, но не копируются флажки для области. Т.о. в родительском процессе kswapd не сможет сделать unmap страницы и следовательно страница всегда будет в памяти, в дочернем же процессе kswapd без проблем сможет делать unmap страниц, поэтому при обращениях к такой области памяти возможен minor fault.

То есть, упрошенно говоря, пока родительский процесс имеет lock на определенную область, эти данные присутствуют в памяти и поэтому в дочернем (и любом другом процессе) не требуют для отображения ввода-вывода.

сорри
а можно еще чуток подробнее
что такое minor fault
и в 2.6 также или по другому ?
----
т.е. в как я понял
если я локнул в родительском
в чилдах лочить не надо

> что такое minor fault

swapper может удалить страницу из адресного пространства
child процесса, т.к. у него эта vm_area_struct (структура,
которая контролирует регион памяти, полученной от mmap())
не имеет флага VM_LOCKED, т.к. child не делал mlock().

когда child обратится к этой странице, будет page fault.
сама же страница никуда не делась, поэтому достаточно
изменить (снова записать) ее в pte процесса, поэтому это
minor fault. вот если бы эта страница был в свопе, ее бы
пришлось читать с диска и был бы major fault.

> и в 2.6 также или по другому

так же

> т.е. в как я понял если я локнул в родительском
> в чилдах лочить не надо

если parent завершится (или сделает unmap/munlock), то
эта память может уйти в своп.

>и в 2.6 также или по другому ?

В 2.6 все так же, только kswapd (или как там его звать) более эффективно осуществляет unmapping страниц, поскольку для каждой страницы может эффективно находить все ее отображения (в 2.4 идет слепой unmapping всего подряд). Что касается locks, то все по-старому.

спасибо по этому вопросу все понял :)
но теперь попутно возник другой вопрос
правильно ли я понимаю суть
ядро хранит для каждого процеса таблицу неких структур данных
по каждой странице памяти, которые как я понимаю
описывают также и некие правила трансляции виртуальных
адресов из пространства процеса на физическую память
ну а при свопе страницы скидываются на диск а физическая
память освобождается для возможного использования другими
процесами например, а в этой таблице делается пометка
типа данная страница находиться в свопе, ну а в случае
обращения к этой странице она из свопа подымается опять в память...
вобще я пытаюсь понять как бы минимизировать потери памяти
т.е. структуры данных описывающие страницы как бы тоже занимают
память, вот и интересно ядро сразу выделят какой-то кусок
под них соответственно объему доступной физической памяти
или для каждого процеса создаются свои структуры ?
вроде как из этого разговора я понял что всеже на каждый процес
но по ходу ядро видимо тогда имеет и свои таблицы
+ при создании процеса опять же как я понимаю выделяется
память под таблицы дескрипторов и т.д. тогда еще один вопрос
сколько минимально поджирается памяти на всякие вспомогательные
структуры ?
-----------
в общем сорри за сумбурность и объемность
спрашиваю то о чем знал поверхностно
но всегда боялся спросить как же оно на самом деле %)

anonymous:

Все адресное пространство процесса покрыто т.н. VMA, т.е. ассоциированными частями файлов(список VMA для процесса можно
посмотреть через cat /proc/pid/maps). VMA - это указатель на файл, смещение от его начала, размер области и права доступа.
Это - software видимость процесса.

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

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

И в "честных" и "нечестных" VM для _VMA, соответствующих файлам,_ ядру не требуются таблицы страницы, т.к. ядро всегда может найти в своем кэше страницу с соответствующими данными либо знает откуда ее нужно прочитать. Но есть еще т.н. _анонимные_VMA_, т.е. VMA без backstore (фактическим backstore для таких VMA является swapfile).
Для страниц анонимной VMA WinNT и Linux хранят в таблицах страниц трансляцию в страницу с данными либо адрес в page файле, если страница swapped.

В Linux память ядра никогда не подкачивается, поэтому для каждого процесса в памяти висят все его VMA и таблицы страниц (kswapd может сделать unmap и тогда для неанонимной VMA он может освобождать соответствующие ячейки таблиц страниц, для анонимной он оставляет ссылку на страницу в pagefile). В WinNT, насколько я помню, они (и VMA и таблицы страниц процесса) могут уходить в pagefile.

Описанное - это упрощенная схема того, как оно есть.

Например, для private mappings при отсутствии трансляции страницы VM создает копию страницы, вместо того, что подсунуть чистую страницу, как происходит с анонимными mappings.

Анонимные VMA получаются, например, после вызовов brk, которым может пользоваться реализация malloc (есть еще другие механизмы создания анонимных VMA). RTLD при загрузке программы создает такие области для сегментов ELF, в которых file size меньше segment size (обычно это т.н. области bss, в которые для C программ проецируются глобальные переменные или локальные статические).

> kswapd может сделать unmap и тогда для неанонимной VMA он может
> освобождать соответствующие ячейки таблиц страниц,

хм... вроде бы, linux этого не делает. то есть, pte страницы так
и болтаются с нулями после try_to_unmap_one(), или я чего-то не
нашел?

кстати, в 2.6 возможно nonlinear mapping, когда для каждой страницы
мы можем указать ее offset в файле. в этом случае в pte (если не
pte_present()) также сидит этот offset.

>хм... вроде бы, linux этого не делает. то есть, pte страницы так
>и болтаются с нулями после try_to_unmap_one(), или я чего-то не
>нашел?

Похоже на правду, хотя в 2.4 никто не мешал делать unmap и пытаться поджимать page tables (берем mmlock, нулим запись в pmd, проверяем целиком ли нулевая страница с pte, отпускаем lock, освобождаем страницу с нулевыми pte или устанавливаем старый pmd... возможно, это слишком медленно для pte_unmap, но можно было бы так делать хотя бы при нехватке памяти). Значит все VMA и page tables для всех процессов постоянно торчат в памяти...

>кстати, в 2.6 возможно nonlinear mapping, когда для каждой страницы
>мы можем указать ее offset в файле. в этом случае в pte (если не
>pte_present()) также сидит этот offset.

Интересно, а в чем смысл? На VMA экономить? Мне не удается придумать разумный пример, когда это дало бы смысл. Да, и как там с обработкой смещений, больших 64 Гб (или для них nonlinear не включается?).

Проблема с нечестными VM - в том, что они не позволяют нормально виртуализировать память, поскольку сильно завязаны на таблицах трансляции. Так, IMHO, для нормальной VM должно быть (на IA32) по 3 Гб виртуального адресного пр-ва на процесс. В реальности же получается 4 Гб на всех(+ОЗУ). Как я понимаю, можно сделать слой над аппаратными таблицами трансляции с полноценными указателями, но тогда вся эта каша в Linux с таблицами трансляции будет вдвойне коряво выгрядеть.

> Интересно, а в чем смысл?

вот и мне стало интересно, специально нашел первый
patch, который ввел sys_remap_file_pages().

> На VMA экономить?

именно это и было написано. типа, для BD.

> Мне не удается придумать разумный пример, когда это дало бы смысл.

и мне не удается! ну никак :)

> Да, и как там с обработкой смещений, больших 64 Гб

без PAE PTE_FILE_MAX_BITS=29, это в страницах

> Так, IMHO, для нормальной VM должно быть (на IA32) по 3 Гб
> виртуального адресного пр-ва на процесс. В реальности же
> получается 4 Гб на всех(+ОЗУ).

этого я что-то не понял.

>без PAE PTE_FILE_MAX_BITS=29, это в страницах

то есть вообще нельзя сделать mmap по смещению, большему 64 Гб, или там nonlinear не будет использоваться?

>этого я что-то не понял.

Ну, условно говоря, за каждой страницей процесса есть либо страница ОЗУ либо страница swap. Итого, на все процессы получается виртуальной памяти - все ОЗУ+все, что PTE могут адресовать на swap (4 Гб).

>Ну, условно говоря, за каждой страницей процесса есть либо страница
>ОЗУ либо страница swap. Итого, на все процессы получается виртуальной
>памяти - все ОЗУ+все, что PTE могут адресовать на swap (4 Гб).

Может я коряво выразился, просто непонятно, почему общий объем виртуальной памяти для системы завязан на устройство MMU (будь это ОЗУ+4Гб для non-PAE, будь то ОЗУ+64 Гб для PAE).

> > без PAE PTE_FILE_MAX_BITS=29, это в страницах
>
> то есть вообще нельзя сделать mmap по смещению, большему 64 Гб,
> или там nonlinear не будет использоваться?

для mmap() у нас ограничение состоит в том, что offset (в страницах!)
должен уместиться в unsigned long, это 16 Tb.

для sys_remap_file_pages() у нас не 32 бита, как в unsigned long, а
PTE_FILE_MAX_BITS, которое при двухуровневых страницах == 29.

поэтому sys_remap_file_pages() работает только в пределах 2 Tb, если
я чего-то не напутал.

> > Ну, условно говоря, за каждой страницей процесса есть либо страница
> > ОЗУ либо страница swap.

нет, это только для тех страниц, для которых нет backing store (swap,
фактически). у нас может быть 8mb памяти и вообще не быть swap, однако
мы вполне (хотя и медленно) можем выполнить 100mb программу, которая
работает с 512mb файлом через mmap().

> > Итого, на все процессы получается виртуальной памяти - все ОЗУ+все,
> > что PTE могут адресовать на swap (4 Гб).

include/asm/pgtable-2level.h:
#define __swp_offset(x)  ((x).val >> 8)

24 бита. это, опять же, в страницах.

то есть, один swap файл/раздел может быть размером 64 Гб, и это,
опять-таки, без PAE. и у нас может быть 2**MAX_SWAPFILES_SHIFT
swap разделов, т.е. 32. так что всего виртуальной памяти намного
больше.

что же касается честных/нечестных vm, то я не очень понимаю, как
можно сделать так, чтобы виртуальной памяти для anonymous страниц
было больше, чем ram + swap.

про кривость я где-то с тобой согласен. все эти pgd_offset() вне
arch/ каталога мне кажутся не слишком элегантными, но как сделать
лучше - я лично не имею представления.

> про кривость я где-то с тобой согласен.

кстати, чтобы жизнь медом не казалась, в mm tree включен
patch для 4-х уровневых страниц.

каждый раз, когда я смотрю на что-нибудь типа
unmap_page_range()->zap_pmd_range()->zap_pte_range(), мне
кажется что можно было бы хотя бы итератор какой-нибудь
придумать для pte walking.

>нет, это только для тех страниц, для которых нет backing store (swap,
>фактически). у нас может быть 8mb памяти и вообще не быть swap, однако
>мы вполне (хотя и медленно) можем выполнить 100mb программу, которая
>работает с 512mb файлом через mmap().

Ну я же уточнил, что говорю про виртуальную память. :)
Может я неточно выразился, но по-моему было вполне понятно,
что речь не об отображенных в память файлах.

>include/asm/pgtable-2level.h:
>#define __swp_offset(x) ((x).val >> 8)
>
>24 бита. это, опять же, в страницах.

А... то есть используются зарезервированные поля в PTE?
Ну да Бог с ним...

>то есть, один swap файл/раздел может быть размером 64 Гб, и это,
>опять-таки, без PAE. и у нас может быть 2**MAX_SWAPFILES_SHIFT
>swap разделов, т.е. 32. так что всего виртуальной памяти намного
>больше.

Такое ощущение будто мы на разных языках говорим. :)

Еще раз: я не пытался считать сколько памяти можно виртулизовать через PTE, я знаю лишь, что ссылка на swapped страницу в swapfile целиком должна поместиться в PTE (верно?), следовательно ограничение на использование swapfile накладывается устройством MMU. Если ты скажешь, что можно использовать свои PTE, то я об этом выше писал и issue насчет ограничений остается.

>что же касается честных/нечестных vm, то я не очень понимаю, как
>можно сделать так, чтобы виртуальной памяти для anonymous страниц
>было больше, чем ram + swap.

Никак. Но можно спроектировать VM так, чтобы в ней нельзя было использовать целиком swapfile (напр. так сделано в Linux).

>про кривость я где-то с тобой согласен. все эти pgd_offset() вне
>arch/ каталога мне кажутся не слишком элегантными, но как сделать
>лучше - я лично не имею представления.

BSD pmap layer

Кстати, недавно дополз до исходников Linux 2.6.
Посмотрел на реализацию /dev/mem (о которой недавно говорили) и прихренел. Может вообще лучше ничего не писать, чем ТАКОЕ?
Ни read/write ни mmap не реализованы нормально.

> Еще раз: я не пытался считать сколько памяти можно виртулизовать
> через PTE, я знаю лишь, что ссылка на swapped страницу в swapfile
> целиком должна поместиться в PTE

а, пардон, я действительно не так тебя понял.
меня эти 4Гб сбили с толку.

> BSD pmap layer

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

еще, вроде, книга была толковая про ейную vm?

idle:

>а, пардон, я действительно не так тебя понял.
>меня эти 4Гб сбили с толку.

Ну я просто считать не умею. :)
Решил, что раз PTE транслирует линейный адрес в 4 Гб физических,
то там только на 4 Гб свободного места. Совсем забыл про резервированные поля. :(

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

На ftp должна быть директория с sources для своей ветки.
И там файлы: ssys.aa ssys.ab ... ssys.al
Их нужно скачать, потом cat ssys.a* > ssys.cpio.gz
Потом развалить. :)

>еще, вроде, книга была толковая про ейную vm?

Есть в сети диссертация по UVM (http://ccrc.wustl.edu/pub/chuck/tech/uvm/), там про NetBSD VM, ну и про ряд других мимоходом. Очень качественно написано, рекомендую, если интересуешься (я по этому ps изучал VM в целом в свое время).

> Посмотрел на реализацию /dev/mem (о которой недавно говорили)

ну, не очень аппетитно выглядит. из-за ifdef'ов особенно.

> Ни read/write ни mmap не реализованы нормально.

то есть?

idle:

Ты не обращай внимания. Я просто люблю потеоретизировать. Я и свой рабочий код то временами перетряхиваю, просто потому что не нравится design. :)

>то есть?

Судя по copy_to_user, в highmem не записать, что может сильно удивить пользователя. mmap вообще будет работать только на highmem или на reserved pages, IIRC.

> На ftp должна быть директория с sources для своей ветки.

ты пальцем, пальцем покажи! :)

вот специально ходил на ftp.freebsd.org, где там src?

нет, просто любопытно, неужели у них нету сервера, откуда
можно взять kernel.tar.gz ???

хотя сейчас у меня все равно времени нет...

Вот как это сделано в FreeBSD:

/* ARGSUSED */
int
memrw(struct cdev *dev, struct uio *uio, int flags)
{
        int o;
        u_int c = 0, v;
        struct iovec *iov;
        int error = 0;
        vm_offset_t addr, eaddr;

        GIANT_REQUIRED;

        while (uio->uio_resid > 0 && error == 0) {
                iov = uio->uio_iov;
                if (iov->iov_len == 0) {
                        uio->uio_iov++;
                        uio->uio_iovcnt--;
                        if (uio->uio_iovcnt < 0)
                                panic("memrw");
                        continue;
                }
                if (minor(dev) == CDEV_MINOR_MEM) {
                        v = uio->uio_offset;
                        v &= ~PAGE_MASK;
                        pmap_kenter((vm_offset_t)ptvmmap, v);
                        o = (int)uio->uio_offset & PAGE_MASK;
                        c = (u_int)(PAGE_SIZE - ((int)iov->iov_base & PAGE_MASK));
                        c = min(c, (u_int)(PAGE_SIZE - o));
                        c = min(c, (u_int)iov->iov_len);
                        error = uiomove((caddr_t)&ptvmmap[o], (int)c, uio);
                        pmap_qremove((vm_offset_t)ptvmmap, 1);
                        continue;
                }
                else if (minor(dev) == CDEV_MINOR_KMEM) {
                        c = iov->iov_len;

                        /*
                         * Make sure that all of the pages are currently
                         * resident so that we don't create any zero-fill
                         * pages.
                         */
                        addr = trunc_page(uio->uio_offset);
                        eaddr = round_page(uio->uio_offset + c);

                        if (addr < (vm_offset_t)VADDR(PTDPTDI, 0))
                                return (EFAULT);
                        for (; addr < eaddr; addr += PAGE_SIZE)
                                if (pmap_extract(kernel_pmap, addr) == 0)
                                        return (EFAULT);

                        if (!kernacc((caddr_t)(int)uio->uio_offset, c,
                            uio->uio_rw == UIO_READ ?
                            VM_PROT_READ : VM_PROT_WRITE))
                                return (EFAULT);
                        error = uiomove((caddr_t)(int)uio->uio_offset, (int)c, uio);
                        continue;
                }
                /* else panic! */
        }
        return (error);
}

/*
 * allow user processes to MMAP some memory sections
 * instead of going through read/write
 */
/* ARGSUSED */
int
memmmap(struct cdev *dev, vm_offset_t offset, vm_paddr_t *paddr,
    int prot __unused)
{
        if (minor(dev) == CDEV_MINOR_MEM)
                *paddr = offset;
        else if (minor(dev) == CDEV_MINOR_KMEM)
                *paddr = vtophys(offset);
        /* else panic! */
        return (0);
}

ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/5.3-RELEASE/src

Цельным gz или bz2 я никогда не встречал. :)

> Судя по copy_to_user, в highmem не записать,
> что может сильно удивить пользователя.

это да, там и явно сказано:
        if (!valid_phys_addr_range(p, &count))
                return -EFAULT;

> mmap вообще будет работать только на highmem или на
> reserved pages

да, но так же всегда было, в 2.4 та же фигня.

>это да, там и явно сказано:

Я ж не спорю. Просто про то, что нельзя читать из highmem я уже понял из copy_to_user. В проверку даже лезть не захотелось (там наверняка еще куски отсекает).

>да, но так же всегда было, в 2.4 та же фигня.

Я думал, что это чей-то глюк. Но раз не поменялось, то значит так и задумывалось? :)

>   int
>   memmmap(struct cdev *dev, vm_offset_t offset, vm_paddr_t *paddr,
>       int prot __unused)

ну, по этой реализации мало что можно понять :)

я думаю, что в linux тоже можно реализовать mmap обычной
памяти.

VM_RESERVED снова в игре, так что, вроде бы, препятствий
особых нет. remap_pte_range() нужно будет менять, конечно.

я, однако, не спорю с тобой в том, что все это есть не очень
красиво.

> ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/5.3-RELEASE/src

погоди, не понял я.

то есть, для _каждой_ архитектуры свой код ядра????

я потому и не стал лезть в i386/, думал, там бинарники.

> Я думал, что это чей-то глюк. Но раз не поменялось,
> то значит так и задумывалось? :)

я думаю, все это тянется с 2.2 еще.

насколько я понимаю, основная проблема в том, чтобы
спасти память mmap(/dev/mem) от swapper'a. и от всякого
рода get_user_pages().

по поводу read/write, тут, по-моему особой разницы
и нет, если в цикле делать kmap()/kumap() получится
что-то похожее на freeBsd код (хотя я его, конечно
не понимаю).

>я думаю, что в linux тоже можно реализовать mmap обычной памяти.

Меня удивляет, почему этого не делают. :(

>погоди, не понял я. > >то есть, для _каждой_ архитектуры свой код ядра???? > >я потому и не стал лезть в i386/, думал, там бинарники.

Скорее просто дерево ftp не очень удачно устроено. Хотя может это я каким-то нелинейным методом пришел к исходникам. :)

>и от всякого рода get_user_pages()

конфликт page->mapping? Это - еще одна корявость Linux. :(

> > и от всякого рода get_user_pages()
>
> конфликт page->mapping? Это - еще одна корявость Linux. :(

а это еще что такое?

да нет, все проще. get_user_pages() делает get_page(). потом
нужно будет сделать put_page(), а т.к. у нас page_count() был 0,
то...

то есть, это то что сразу видно, наверное и еще есть проблемы.

кстати, надо сказать, что get_user_pages() сильно изменилась
с тех пор, как я туда последний раз заглядывал. и не в сторону
упрощения...

Murr, последний абзац - это все твое тлетворное влияние!

я все-таки думаю, что в общем и целом linux далеко не самый
плохой пример кодирования.

>а это еще что такое?

Это адресное пр-во, которой принадлежит страница.
В данном случае мы создаем AS, отличное от адресного
пр-ва, к которому принадлежит страница.

>да нет, все проще. get_user_pages() делает get_page(). потом
>нужно будет сделать put_page(), а т.к. у нас page_count() был 0,
>то...

С count ничего не понял. :(
Это же обычный счетчик пользователей mem_map entry.
По-честному мы для /dev/mem для каждой страницы должны
делать get_page (и потом put_page). Это не концептуальная
проблема. Просто этого не делается, потому что
/dev/mem mapping is very special. :)
Вот конфликт AS - это уже проблема.

>кстати, надо сказать, что get_user_pages() сильно изменилась
>с тех пор, как я туда последний раз заглядывал. и не в сторону
>упрощения...

Да, есть немного. Мне, кстати, очень нравится эта функция. :)
В свое время даже была привычка использовать ее и kmap вместо copy_from_user/copy_to_user (ну не нравится мне эта парочка
и все тут).

> > а это еще что такое?
>
> Это адресное пр-во, которой принадлежит страница.
> В данном случае мы создаем AS, отличное от адресного
> пр-ва, к которому принадлежит страница.

нет, это я понимаю. я не понимаю, как это ломает get_user_pages.
мы вообще не смотрим здесь на page_mapping().

хотя, я уже вотки выпил, так шта :)

> Это же обычный счетчик пользователей mem_map entry.
> По-честному мы для /dev/mem для каждой страницы должны
> делать get_page (и потом put_page)

да, но mmap(/dev/mem) использует remap_pfn_range(),
который этот счетчик _не_ увеличивaет, и он остается
нулем. после get_user_pages()/put_page мы получаем
__page_cache_release() и следующий процесс, которому
понадобится память получит то, что еще недавно было
кодом для schedule().

> Это не концептуальная проблема.

согласен, все это можно решить. но, по-моему, лучше
начинать от VM_RESERVED в vma, как это делается в
mm/rmap.c, и просто не играться с page->_count в таких
vma.

>нет, это я понимаю. я не понимаю, как это ломает get_user_pages.
>мы вообще не смотрим здесь на page_mapping().

с get_user_pages все ок. Проблема может случиться, если кто-то еще в ядре потом полезет в page->mapping (какой бы он не был - он все равно всегда один).

>хотя, я уже вотки выпил, так шта :)

Уважаю. :)

Я сейчас тоже слегка заправлюсь - только надо подсохнуть после ванны и пройти 20м до ближайшего вино-водочного(или 50м до Патерсона).

Выдул бутылку шампанского. Блин, пиво просто отдыхает по сравнению с шампанским. Уже соображаю с трудом.

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

PS. Murr, idle спасибо за ответы
и вобще за изложение мыслей. Всегда с интересом читаю
ваши мессаги.

автор темы

автору темы:

>Шампанское хорошо но только отпускает быстро очень :)

Это да. Но в больших количествах - не сразу. :)
А вот сушняк утром был - просто чумовой. :(

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

Это было бы интересно, жаль только на LOR темы быстро спускаются. :(

>PS. Murr, idle спасибо за ответы
>и вобще за изложение мыслей. Всегда с интересом читаю
>ваши мессаги.

Мои сообщения стоит читать с некой толикой скептицизма.
Просто я обычно в форум пишу не отрываясь от просмотра
кино или кодирования и временами делаю ляпы, например,
не до конца дочитываю вопрос или делаю ляпы в подсчетах
(хотя по существу вроде как ляпов должно быть немного),
а вот комментарии idle - да, обычно точны и выверены. :)

Удачи. :)