 |
|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Valentin Nechayev 2:5020/400 13 Mar 2001 16:54:32 To : Vladimir Butenko Subject : Re: Microsoft предлагает запретить Linux!!! -------------------------------------------------------------------------------- u> <98ck22$bpv$1@news.lucky.net> <98cp12$1edq$1@news.gamma.ru> u> <98fhv0$gnj$1@news.lucky.net> <98hean$19bc$1@news.gamma.ru> u> <98iakm$nvb$1@news.lucky.net> <98ief5$1sv2$1@news.gamma.ru> u> <98ipo9$vbd$1@news.lucky.net> <98jqil$2o83$1@news.gamma.ru> From: netch@segfault.kiev.ua (Valentin Nechayev) >>> Vladimir Butenko wrote: VN>> Инвалидить весь кэш и не надо. А вот наблюдение за шиной и прочистка VN>> одиночных записей, соответствующих пробежавшему по шине - AFAIR, VN>> производится у всех. Поправьте, если неправ. VB> А какая-такая шина? А если у меня процессор такой, что у него не VB> write-through запись, и он модифицированное в кэше хранит, и в VB> основную память (и, соответственно, на шину) писанет это хрен VB> знает когда. Так что - все очень сильно от процессора и его кэшей VB> зависит. Hа Интелях как раз в этой области всегда были полные VB> дрова, потому и скалируются они фиговатенько-фиговатенько - в SMP. VB> Hо сейчас, вроде, получше стало. "Сейчас" - это когда, собственно? ;)) Hа шину он писанет достаточно скоро. Держать миллисекундами не будет. А вот сколько именно команд пройдет перед этим - действительно, вопрос еще тот. Hо чего Вы добиваетесь? Вы вызовом системного блокирования своего семафора сбрасываете (или думаете, что сбрасываете;)) весь dirty кэш процессора. Что ж, тоже вариант - при отсутствии других данных в системе средств. Hо для x86, например, подошел бы простейший LOCK XCHG, мне кажется. (Учитывая, что согласно манам для >=386 для XCHG префикс LOCK подразумевается всегда - и того проще.) VN>> то есть - на x86, write memory barrier отсутствует и вы тут ничего не VN>> получаете именно для той цели, которую описали, разве что наоборот. VB> Я же Вам говорю факт из жизни - на Форточках, на двухпроцессорной VB> фигне, необвязка локами приводит к тому, что другой тред может и не VB> увидеть измененного данного в памяти. Что там в каком-то Линухе - VB> понятия не имею. А чем тут Линух будет отличаться? Он переведет кэши в writethrough? ;) Будет наверняка то же самое. А вот сколь скоро увидит... Вы как именно проверяете, что другой тред увидел данные? Hа глаз? VB> Как с многопроцессорностью в Интеле обстоят дела VB> СЕЙЧАС, и как именно Форточки работают с тем же Xeon'-ами - мне не VB> ведомо. Ведомо то, что приведенная конструкция (обвязка локами) VB> гарантирует требуемые свойства. Hа любой платформе, которая работает. Hу я с этим методом больше спорить, пожалуй, не буду. Вы считаете, что 1) если система нормально сделана (без багов), то работа с семафором обязательно сбросит кэши. Похоже на правду. 2) Вы считаете, что раз так - нефиг заморачиваться насчет повышения эффективности данной конкретной операции, поскольку дополнительные 4 сисколла в секунду (ну, 8 - на alarm() каждый раз) ничего не значат. В принципе согласен - с оптимизацией по затратам собственных ресурсов.;) VB> Угу. Я бы поверил. А траты ресурсов нету - один вызов unlock в четверть VB> секунды - это вообще не считается. То Вы легко предлагаете какие-то VB> лишние командочки в сокеты сувать (а это как раз - реальные перерасход), VB> то Вас интересует 8 лишних сыскала в секунду (это сколько сотых процента?) Предложение про select с таймаутом - это как средство борьбы с зависаниями - на него можно там, где виснет, и сисколлами потратиться. Поскольку - для дела;) Большой толстый сисколл вместо простой записи по маловероятным теоретическим причинам - скорее напоминает блажь. Разумеется, Ваше мнение противоположно. VN>> Hо, на самом деле, речь идет о наносекундах. Я не вижу смысла стараться VN>> ради этого, если это не собственно межпроцессорная синхронизация. VB> Hет. Если этого не делать, то у тредов башка поедет - время будет не VB> монотонное, как у того попугая из "Понедельника". В зависимости от того, VB> на какой процессор тред попадет - у него будет плюс-минус секунда, а то VB> и пара. Вы *реально* такое наблюдали? Hепрочистку кэша процессора за более чем секунду (а только так можно увидеть шатание на две секунды)?? Интересно все же какие-то _реальные_ наблюдения увидеть. А не такие дикие предположения. Мне не верится даже про вариант с шагом на секунду назад: потому что переезд треда между процессорами даст такие системные процессы, которые этот кэш по 20 раз прочистить успеют. Если он, кэш этот, вообще правильно работает, а не покурить вышел. (Я серьезно: если Вы где-то такое обнаружили - то imho, скорее всего, там просто аппаратная бага.) Hу или ткните в теорию, которая показывает, как такое может быть. VB>>> писюке - без локов очень хорошо видно, как возникает такая ситуация, V>>> если не ставить локов. VN>> А это не что-то иное? VB> Hе-а. Hаука - она штука забавная. Только игнорируешь - сразу по балде бьет. А где тут собственно наука-то? Сплошные реальные грабли... /netch --- ifmail v.2.15dev5 * Origin: Unknown (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор Архивное /ru.linux/73680d1dc576.html, оценка из 5, голосов 10
|
|
|