Re: semtimedop instead of setitimer/semop/setitimer
От | Manfred Spraul |
---|---|
Тема | Re: semtimedop instead of setitimer/semop/setitimer |
Дата | |
Msg-id | 3F6C9933.6060400@colorfullife.com обсуждение исходный текст |
Ответ на | Re: semtimedop instead of setitimer/semop/setitimer (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: semtimedop instead of setitimer/semop/setitimer
|
Список | pgsql-hackers |
Tom Lane wrote: >Manfred Spraul <manfred@colorfullife.com> writes: > > >>... Initially I tried to increase MAX_ALIGNOF to 16, but >>the result didn't work: >> >> > >You would need to do a full recompile and initdb to alter MAX_ALIGNOF. > I think I did that, but it still failed. 7.4cvs works, I'll ignore it. MAX_ALIGNOF affects the on-disk format, correct? Then I agree that it's the wrong to change it. >However, if you are wanting to raise it past about 8, that's probably >not the way to go anyway; it would create padding wastage in too many >places. It would make more sense to allocate the buffers using a >variant ShmemAlloc that could be told to align this particular object >on an N-byte boundary. Then it costs you no more than N bytes in the >one place. > I agree, I'll write a patch. >(BTW, I wonder whether there would be any win in allocating the buffers >on a 4K or 8K page boundary... do any kernels use virtual memory mapping >tricks to replace data copying in such cases?) > Linux doesn't. Page table games are considered as evil, because tlb flushing is expensive, especially on SMP. -- Manfred
В списке pgsql-hackers по дате отправления: