python的mmap
㈠ python標准庫有哪些
Python標准庫的內容涵蓋了非常多的功能，主要包括文件、字元串和數字處理，數據結構、網路編程、操作系統用戶界面、網頁測試、線程以及其它的工具。
具體有，1、文件操作相關的模塊，os，os。
path，shutil，errno，stat，glob，fnmatch，tempfile等。
2、字元串和文本處理模塊，string，re，difflib和textwrap等。
3、數據結構形式，collections，bisect，array，heapq，queue，struct和weakref等。
4、網路編程與操作系統，SocketServer，socket，selectselectors，threading，multiprocessing，subprocess，mmap，sched，asyncore等。
5、網頁測試，urllib，扮態urllib2，配則httplib，ftplib，gopherlib，spider等。
6、解析和處理XML，HTMLParser，ElementTree，XMLParser，XMLWriter，SAX，minidom，expat等。
7、除此之廳賣源外，還包含一些其他方便實用的部分，如BaseHTTPServer，CGIHTTPServer，Cookie，templating，xmlrpclib，formatter，email等。
此外，Python還支持第三方庫和框架，有很多實用的框架和工具可以讓開發者高效、便捷地完成國家工作。
㈡ 在python中一共有多少個標准庫
Python 語言官方的參考手冊鍾，介紹了與 Python 一同發行的標准庫。
文本處理服務
string--- 常見的字元串操作
re--- 正則表達式操作
difflib--- 計算差異的輔助工具
textwrap--- 文本自動換行與填充
unicodedata--- Unicode 資料庫
stringprep--- 網際網路字元串預備
readline--- GNU readline 介面
rlcompleter--- GNU readline 的補全函數
二進制數據服務
struct--- 將位元組串解讀為打包的二進制數據
codecs--- 編解碼器注冊和相關基類
數據類型
datetime--- 基本日期和時間類型
zoneinfo--- IANA 時區支持
calendar--- 日歷相關函數
collections--- 容器數據類型
collections.abc--- 容器的抽象基類
heapq--- 堆隊列演算法
bisect--- 數組二分查找演算法
array--- 高效的數值數組
weakref--- 弱引用
types--- 動態類型創建和內置類型名稱
--- 淺層 (shallow) 和深層 (deep) 復制操作
pprint--- 數據美化輸出
reprlib--- 另一種repr()實現
enum--- 對枚舉的支持
graphlib--- 操作類似圖的結構的功能
數字和數學模塊
numbers--- 數字的抽象基類
math--- 數學函數
cmath--- 關於復數的數學函數
decimal--- 十進制定點和浮點運算
fractions--- 分數
random--- 生成偽隨機數
statistics--- 數學統計函數
函數式編程模塊
itertools--- 為高效循環而創建迭代器的函數
functools--- 高階函數和可調用對象上的操作
operator--- 標准運算符替代函數
文件和目錄訪問
pathlib--- 面向對象的文件系統路徑
os.path--- 常用路徑操作
fileinput--- 迭代來自多個輸入流的行
stat--- 解析stat()結果
filecmp--- 文件及目錄的比較
tempfile--- 生成臨時文件和目錄
glob--- Unix 風格路徑名模式擴展
fnmatch--- Unix 文件名模式匹配
linecache--- 隨機讀寫文本行
shutil--- 高階文件操作
數據持久化
pickle--- Python 對象序列化
reg--- 注冊配合pickle模塊使用的函數
shelve--- Python 對象持久化
marshal--- 內部 Python 對象序列化
dbm--- Unix "資料庫" 介面
sqlite3--- SQLite 資料庫 DB-API 2.0 介面模塊
數據壓縮和存檔
zlib--- 與gzip兼容的壓縮
gzip--- 對gzip格式的支持
bz2--- 對bzip2壓縮演算法的支持
lzma--- 用 LZMA 演算法壓縮
zipfile--- 使用ZIP存檔
tarfile--- 讀寫tar歸檔文件
文件格式
csv--- CSV 文件讀寫
configparser--- 配置文件解析器
tomllib--- Parse TOML files
netrc--- netrc 文件處理
plistlib--- 生成與解析 Apple.plist文件
加密服務
hashlib--- 安全哈希與消息摘要
hmac--- 基於密鑰的消息驗證
secrets--- 生成管理密碼的安全隨機數
通用操作系統服務
os--- 多種操作系統介面
io--- 處理流的核心工具
time--- 時間的訪問和轉換
argparse--- 命令行選項、參數和子命令解析器
getopt--- C 風格的命令行選項解析器
logging--- Python 的日誌記錄工具
logging.config--- 日誌記錄配置
logging.handlers--- 日誌處理程序
getpass--- 攜帶型密碼輸入工具
curses--- 終端字元單元顯示的處理
curses.textpad--- 用於 curses 程序的文本輸入控制項
curses.ascii--- 用於 ASCII 字元的工具
curses.panel--- curses 的面板棧擴展
platform--- 獲取底層平台的標識數據
errno--- 標准 errno 系統符號
ctypes--- Python 的外部函數庫
並發執行
threading--- 基於線程的並行
multiprocessing--- 基於進程的並行
multiprocessing.shared_memory--- Shared memory for direct access across processes
concurrent包
concurrent.futures--- 啟動並行任務
subprocess--- 子進程管理
sched--- 事件調度器
queue--- 一個同步的隊列類
contextvars--- 上下文變數
_thread--- 底層多線程 API
網路和進程間通信
asyncio--- 非同步 I/O
socket--- 底層網路介面
ssl--- 套接字對象的 TLS/SSL 包裝器
select--- 等待 I/O 完成
selectors--- 高級 I/O 復用庫
signal--- 設置非同步事件處理程序
mmap--- 內存映射文件支持
互聯網數據處理
email--- 電子郵件與 MIME 處理包
json--- JSON 編碼和解碼器
mailbox--- 操作多種格式的郵箱
mimetypes--- 映射文件名到 MIME 類型
base64--- Base16, Base32, Base64, Base85 數據編碼
binascii--- 二進制和 ASCII 碼互轉
quopri--- 編碼與解碼經過 MIME 轉碼的可列印數據
結構化標記處理工具
html--- 超文本標記語言支持
html.parser--- 簡單的 HTML 和 XHTML 解析器
html.entities--- HTML 一般實體的定義
XML處理模塊
xml.etree.ElementTree--- ElementTree XML API
xml.dom--- 文檔對象模型 API
xml.dom.minidom--- 最小化的 DOM 實現
xml.dom.pulldom--- 支持構建部分 DOM 樹
xml.sax--- 支持 SAX2 解析器
xml.sax.handler--- SAX 處理句柄的基類
xml.sax.saxutils--- SAX 工具集
xml.sax.xmlreader--- 用於 XML 解析器的介面
xml.parsers.expat--- 使用 Expat 的快速 XML 解析
互聯網協議和支持
webbrowser--- 方便的 Web 瀏覽器控制工具
wsgiref--- WSGI 工具和參考實現
urllib--- URL 處理模塊
urllib.request--- 用於打開 URL 的可擴展庫
urllib.response--- urllib 使用的 Response 類
urllib.parse用於解析 URL
urllib.error--- urllib.request 引發的異常類
urllib.robotparser--- robots.txt 語法分析程序
http--- HTTP 模塊
http.client--- HTTP 協議客戶端
ftplib--- FTP 協議客戶端
poplib--- POP3 協議客戶端
imaplib--- IMAP4 協議客戶端
smtplib--- SMTP 協議客戶端
uuid---RFC 4122定義的UUID對象
socketserver--- 用於網路伺服器的框架
http.server--- HTTP 伺服器
http.cookies--- HTTP狀態管理
http.cookiejar—— HTTP 客戶端的 Cookie 處理
xmlrpc--- XMLRPC 服務端與客戶端模塊
xmlrpc.client--- XML-RPC 客戶端訪問
xmlrpc.server--- 基本 XML-RPC 伺服器
ipaddress--- IPv4/IPv6 操作庫
多媒體服務
wave--- 讀寫WAV格式文件
colorsys--- 顏色系統間的轉換
國際化
gettext--- 多語種國際化服務
locale--- 國際化服務
程序框架
turtle--- 海龜繪圖
cmd--- 支持面向行的命令解釋器
shlex—— 簡單的詞法分析
Tk圖形用戶界面(GUI)
tkinter—— Tcl/Tk 的 Python 介面
tkinter.colorchooser--- 顏色選擇對話框
tkinter.font--- Tkinter 字體封裝
Tkinter 對話框
tkinter.messagebox--- Tkinter 消息提示
tkinter.scrolledtext--- 滾動文字控制項
tkinter.dnd--- 拖放操作支持
tkinter.ttk--- Tk 風格的控制項
tkinter.tix--- TK擴展包
㈢ mmap是什麼格式的文件怎麼打開
mmap：是MindManager導圖默認的官方保存格式，也是使用最多的保存格式。
MindManager作為專業實用性軟體，和其他的軟體有很好的兼容性，從MindManager的導出格式上就可以看出來，MindManager支持15種導出格式，完全滿足用戶的所有需求，本教程將主講MindManager思維導圖的導出格式。
MindManager 2019 win版 :點擊免費獲取MindManager 2019下載地址
MindManager 11 Mac版 :點擊免費獲取MindManager 下載地址
打開MindManager思維導圖軟體，製作好導圖。點擊文件→另存為。在文件另存為對話框內點擊保存類型右邊的倒置三角，即可打開導圖的保存格式列表。
mmap：是MindManager導圖默認的官方保存格式，也是使用最多的保存格式。
xmmap、xml：是另一種MindManager導圖的保存格式。
mmat、xmmat：是MindManager模板較常用的保存格式。
ppt、pot：是將MindManager導圖保存為PPT格式，方便文稿演示。
docx、dotx、doc、dot：是將MindManager導圖保存為Word文檔，便於存儲。
pdf：是將MindManager導圖保存為PDF文件，PDF是互動式只讀文件，便於查閱。
swf：是將MindManager導圖保存為swf格式，便於插入到網頁和在Flash瀏覽器中查看。
jpeg、jpg：是將MindManager導圖保存為圖片的格式。
以上格式是MindManager最常見的導出格式，其他的格式需要專業的軟體才能打開，用戶使用的也比較少，在此不作詳解。
㈣ 如何用Python一門語言通吃高性能並發，GPU計算和深度學習
第一個就是並發本身所帶來的開銷即新開處理線程、關閉處理線程、多個處理線程時間片輪轉所帶來的開銷。
實際上對於一些邏輯不那麼復雜的場景來說這些開銷甚至比真正的處理邏輯部分代碼的開銷更大。所以我們決定採用基於協程的並發方式，即服務進程只有一個(單cpu)所有的請求數據都由這個服務進程內部來維護，同時服務進程自行調度不同請求的處理順序，這樣避免了傳統多線程並發方式新建、銷毀以及系統調度處理線程的開銷。基於這樣的考慮我們選擇了基於Tornado框架實現api服務的開發。Tornado的實現非常簡潔明了，使用python的生成器作為協程，利用IOLoop實現了調度隊列。
第二個問題是資料庫的性能，這里說的資料庫包括MongoDB和Redis，我這里分開講。
先講MongoDB的問題，MongoDB主要存儲不同的用戶對於驗證的不同設置，比如該顯示什麼樣的圖片。
一開始每次驗證請求都會查詢MongoDB，當時我們的MongoDB是純內存的，同時三台機器組成一個復制集，這樣的組合大概能穩定承載八九千的qps，後來隨著我們驗證量越來越大，這個承載能力逐漸就成為了我們的瓶頸。
為了徹底搞定這個問題，我們提出了最極端的解決方案，乾脆直接把資料庫中的數據完全緩存到服務進程里定期批量更新，這樣查詢的開銷將大大降低。但是因為我們用的是Python，由於GIL的存在，在8核伺服器上會fork出來8個服務進程，進程之間不像線程那麼方便，所以我們基於mmap自己寫了一套夥伴演算法構建了一個跨進程共享緩存。自從這套緩存上線之後，Mongodb的負載幾乎變成了零。
說完了MongoDB再說Redis的問題，Redis代碼簡潔、數據結構豐富、性能強大，唯一的問題是作為一個單進程程序，終究性能是有上限的。
雖然今年Redis發布了官方的集群版本，但是經過我們的測試，認為這套分布式方案的故障恢復時間不夠優秀並且運維成本較高。在Redis官方集群方案面世之前，開源世界有不少proxy方案，比如Twtter的TwemProxy和豌豆莢的Codis。這兩種方案測試完之後給我們的感覺TwemProxy運維還是比較麻煩，Codis使用起來讓人非常心曠神怡，無論是修改配置還是擴容都可以在配置頁面上完成，並且性能也還算不錯，但無奈當時Codis還有比較嚴重的BUG只能放棄之。
幾乎嘗試過各種方案之後，我們還是下決心自己實現一套分布式方案，目的是高度貼合我們的需求並且運維成本要低、擴容要方便、故障切換要快最重要的是數據冗餘一定要做好。
基於上面的考慮，我們確定基於客戶端的分布式方案，通過zookeeper來同步狀態保證高可用。具體來說，我們修改Redis源碼，使其向zookeeper注冊，客戶端由zookeeper上獲取Redis伺服器集群信息並根據統一的一致性哈希演算法來計算數據應該存儲在哪台Redis上，並在哈希環的下一台Redis上寫入一份冗餘數據，當讀取原始數據失敗時可以立即嘗試讀取冗餘數據而不會造成服務中斷。
㈤ 菜鳥關於linux下裝應用程序的問題
Linux 操作系統、構建工具和多數語言的編譯器可免費獲得並可從網際網路上下載。為了開始移植，您將需要提供硬體和開發人員：
第 1 步 — 下載所需的開發工具和 Linux 分發版。
第 2 步 — 改用 Linux 開發工具但仍然運行 Solaris。這種方法使得轉變更平緩。
第 3 步 — 熟悉 Linux 操作系統但仍舊在 Sun 硬體上運行。
第 4 步 — 把應用程序移到目標 Linux 平台。
第 1 步：下載
以下列出的是所需的編譯器、構建工具和相關的在線文檔鏈接：
GCC（GNU Compiler Collection）工具套件包含一個 C 編譯器和一個 C++ 編譯器
gcc.gnu.org/releases.html
在線文檔
gcc.gnu.org/onlinedocs/gcc-2.95.2/gcc_toc.html
Solaris GNU 編譯器和 make（gmake）實用程序
www.sunfreeware.com/
在線文檔
docs.sun.com/
gnu.org/manual/make-3.79.1/html_mono/make.html
Linux 可從以下 Linux 發行商那裡獲得。
Caldera www.caldera.com/
Red Hat www.redhat.com/
SuSE www.suse.com/
Turbolinux www.turbolinux.com/
— Linux 的 UltraSPARC 版本
Sun www.sun.com
第 2 步：為 Solaris 上的 Linux 構建您的 C/C++ 應用程序
安裝工具 — 先在 Solaris 上安裝 GNU 工具。由於 GNU 編譯器和 make 實用程序在 Solaris 和 Linux 上都能用，所以使用這些工具來嘗試初次構建您的 Linux 應用程序相對較容易。
轉換 makefile — 構建您的應用程序時請用 GNU gmake 實用程序，別用 Solaris make 實用程序。根據您的 makefile 中用到的構造，您可能遇到 GNU gmake 實用程序產生的錯誤消息，因為 GNU gmake 實用程序和 Solaris make 實用程序是有區別的。請用 make 工具文檔來幫助找出 makefile 中有問題的地方，然後對 makefile 作出所需的調整。
編譯和調試 — 當您通過修改您的 makefile、使之能被 gmake 使用後，把 makefile 中調用 C 編譯器的名字 cc 改為 gcc，C++ 編譯器的名字 CC 改為 g++。然後編譯該應用程序。您在構建中所遇到的錯誤消息，如果有的話，可被分成兩類：命令行選項問題和代碼問題。
找出由於 GNU 和 Sun 編譯器所接受的命令行選項有所不同而產生的消息。除了幾個基本選項（例如「-c」和「-g」），兩個編譯器能接受的多數選項是不同的。請參閱編譯器文檔，修改您的 makefile，以適應編譯器選項間的區別。
下一步，您可以處理剩下的與代碼有關的錯誤消息和警告。請參閱編譯器文檔，理解並解決由於編譯器之間的差別而產生的問題。
第 3 步：在 Linux 的 Sun UltraSPARC 版本上構建和測試您的應用程序。
如果所移植的應用程序依賴特定的 UltraSPARC 硬體，那麼這是移植過程中的重要階段。Solaris 開發者有機會熟悉 Linux 環境而不必放棄下層的 UltraSPARC 硬體，也不必修改應用程序中特定於硬體的部分。
安裝 Linux 環境 — 在 Sun UltraSPARC 上，安裝 Linux 和 GNU 實用程序。
編譯並調試運行時 API — 因為您在構建您的應用程序時用的是 GNU 實用程序，所以您在這步看到的區別限於 Solaris 和 Linux 之間的運行時應用程序編程介面（application programming interfaces，API）的區別。如果您想了解這些區別的更多信息，請參閱運行時介面部分（第 7 頁）。對應用程序作出所需的調整。
測試 — 當應用程序被完全地重新構建後，進行徹底的驗證測試。
第 4 步：在目標 Linux 平台上構建和測試您的應用程序。
安裝 Linux 環境 — 在目標硬體上安裝 Linux 和 GNU 工具。
復制並重新構建應用程序 — 把您的源代碼樹和 makefile 復制到新的 Linux 機器上並重新構建應用程序。如果您沒完成第 3 步，那麼您可能需要修改應用程序，以適應 Solaris 和 Linux 之間運行時 API 的區別。最後，如果您的應用程序包含任何特定於 UltraSPARC 的代碼，那麼，請作出所需的修改，以解決那部分代碼的問題。
修改安裝常式，以適應目標 Linux 平台。各種 Linux 平台（分發版）的配置和啟動文件的位置稍有不同。
測試 — 在結束移植前，對移植的應用程序運行徹底的驗證測試套件。另外，在目標 Linux 平台上測試配置和安裝。
警告！許可證和版權條款 — 當您移植到 Linux 並把您的應用程序和開放源代碼的庫鏈接時，請注意和這些庫有關的許可證和版權。至少來說，您新移植的 C/C++ 應用程序將被鏈接到 GNU C/C++ 運行時庫。這些庫受 GNU Lesser General Public License 的保護。如果您移植的軟體是專利性質的並且您想在用 GNU 工具構建該軟體後出售它，那麼謹慎的作法是完全理解 GNU General Public License 和 GNU Lesser General Public License（www.gnu.org/licenses/licenses.html）中列出的條款和條件。如果您的軟體和受 GNU 許可證保護的庫鏈接，那麼 GNU 許可證中的某些條款和條件將對您的軟體也適用。
java 應用程序的移植指南
第 1 步 — 下載所需的開發工具。
第 2 步 — 在目標 Linux 平台上使用應用程序。
第 1 步：下載
把用 Java 寫的應用程序的開發從 Solaris 移到 Linux 是很簡單的。您移植任務所需的工具有：
Java 2 Developer Kit 的 Linux 版包括重建的 Java 虛擬機（Java Virtual Machine，JVM），該 JVM 有改進的即時（just-in-time）編譯功能 ibm.com/developerworks/java/jdk/linux130/
GCC 工具套件包含一個 Java 編譯器（GCJ）gnu.org/software/gcc/java/
第 2 步：在目標 Linux 平台上使用應用程序
無論 JVM 運行在什麼操作系統上，JVM 接受同樣的位元組碼，所以您可以選擇在某個操作系統中編譯 Java 源文件，然後在另一操作系統中運行生成的類文件。例如，如果 Linux 是您的主要開發平台，那麼您在 Linux 上創建的 Java 類文件能同樣好地運行在 Solaris 或其它有兼容 JVM 的平台上。
運行時介面
盡管 Linux 和 Solaris 的絕大部分運行時介面是相同的，但有些地方還是有區別的。在您的應用程序中，每處用到 Linux 上沒有或不完全相同的 Solaris 介面的地方都需要被修改，否則您的應用程序無法被正確地構建。以下列出的是有區別的地方。
系統調用、C 庫和 C++ 庫
API 差別 — Solaris 內核提供邏輯卷支持、文件的訪問控製表（Access control list，ACL）的管理和系統審計日誌功能。Linux API 中的這些功能（如果有的話）與 Solaris 上的並不相同。還有，在預設情況下，Linux 不支持 STREAMS。在網路中用到 STREAMS 的應用程序需要改用 POSIX 套接字。另外，不少 Linux 上也有的 Solaris API 使用不同的返回和參數類型，或在不同的頭文件中聲明。但是，這些差別往往不大，通常不需要在應用程序中修改代碼。
C++ 庫 — Solaris Forte 6 C++ Compiler 包含三個類庫：復數（-compat=4）、經典 iostream 和 Standard C++ Library（它包含標準的復數和 iostream）。GCC 只包含 Standard C++ Library。如果所移植的應用程序使用 -compat=4 復數庫或經典 iostream 庫，那麼應用程序需改用包含在 Standard C++ Library 中的那些庫的標准版本。作這種修改的額外好處是提高了應用程序的可移植性。
桌面：CDE 對 GNOME/KDE
圖形用戶界面（graphical user interface，GUI）— Solaris 的預設桌面 Common Desktop Environment（CDE）並不包含在常見的 Linux 分發版中。對於要求 CDE 的應用程序或偏愛這種特別的 GUI 環境的用戶，CDE 的 Linux 版本可從 Xi Graphics（www.xig.com）以他們的 DeXtop 產品的形式獲得。在 Linux 上運行 DeXtop 使 Solaris 用戶置身於熟悉的 GUI 環境從而使他們很容易地適應轉移到 Linux 所帶來的變化。
DeXtop 要求使用也是由 Xi Graphics 提供的 Accelerated-X Linux X-Server。盡管 XFree86 Linux X-Server 可以和 DeXtop 一起運行，但是 Xi Graphics 並不正式支持在 XFree86 上運行 DeXtop。
線程和進程管理
線程／輕量級進程（Light Weight Process，LWP）支持 — Solaris 支持 POSIX 線程和特定於 Solaris 的線程模型。如果所移植的應用程序使用特定於 Solaris 的線程 API，那麼，最好修改應用程序，使其改用 POSIX 線程。POSIX 線程的可移植性更好而且 Linux 也支持它。
進程管理：/proc 文件系統 — /proc 偽文件系統提供了訪問內核數據結構的方便的方法。在 Solaris 上，/proc 包括關於活動的進程和線程的信息，/proc 還提供控制這些進程和線程的介面。Solaris 上的 /proc 控制介面通常被調試器用來跟蹤程序的執行。在 Linux 上，/proc 並不提供進程式控制制介面。在 Linux 上調試時，為了控制進程，請用 ptrace() API 而不是 /proc。
運行時要考慮的因素
系統管理：一般地說，管理 Linux 和管理任何其它 UNIX 操作系統非常相似。但在某些命令和任務的細節上是有差別的。IBM 和 UNIXGuide（unixguide.net/unixguide.cgi）已出版了比較圖表，該圖表不僅總結了 Solaris 和 Linux 之間的一些差別，還總結了 AIX 和其它版本的 UNIX 之間的差別。有經驗的 Solaris 系統管理員不會遇到多大困難就能得心應手地用 Linux。
其它第三方工具、實用程序和庫：許多 Solaris 上常見的流行的第三方工具、實用程序和庫在 Linux 上也有，例如：
Rational Rose 和其它 Rational 產品在 Solaris 和 Linux 上都能用。
Rogue Wave SourcePro C++ 庫在 Forte/Solaris 上能用，在 GCC/Solaris 和 GCC/Linux 上也能用。
Trolltech Qt C++ GUI 框架在 Solaris 和 Linux 上都能用。
由於 Linux 越來越受到歡迎，支持 Linux 的第三方供應商的數量在不斷增加。
尾數格式 — Sun SPARC 和 UltraSPARC 處理器用大尾數法格式存儲整數。如果您想把應用程序移植到使用小尾數法的 Linux 版本，例如 Linux/Intel，那麼您必須解決應用程序中所有的尾數格式的相關性，以使應用程序能正確運行。另一種方法是把應用程序移植到 Linux/PowerPC、zSeries 上的 Linux 或 Linux/UltraSPARC（它們都是大尾數法平台）而不是 Linux/Intel。
從 Linux 移植到 zSeries 上的 Linux
現在移植到一個平台上（比如說 Intel）的 Linux 已完成，那麼移植到其它硬體平台上的 Linux 怎樣呢？簡短的回答是：這很容易。
由於以下兩個原因，我們選擇以 zSeries 為例。
zSeries 是容易地從一種 Linux 移植到另一種 Linux 的好例子，因為 zSeries 體系結構和 Intel 體系結構完全不同。許多 ISV 先把他們的 UNIX 應用程序移植到 Intel 上的 Linux，這當然是自然的選擇。接著再把應用程序移植到 zSeries 上的 Linux 就不需要太多的努力。
由於 zSeries 在虛擬化領域的獨特功能及其硬體可靠性和可用性，所以，對您來說，zSeries 可能是有吸引力的平台。
為什麼要移植到 zSeries 上的 Linux？
zSeries 上的 Linux 是純粹的 Linux：它不是現有的 zSeries 操作系統上特別的 Linux，也不是為 zSeries 體系結構而修改的 Linux 的特別版本。zSeries 上的 Linux 的特徵與其它平台上的 Linux 的特徵相同，例如它是純粹的 ASCII 環境。對於所有的體系結構，絕大部分的 Linux 結構是相同的。和 zSeries 相關的修改使 Linux 能和 zSeries 內存、zSeries 磁碟及通信硬體進行通信。Linux 和應用程序的介面及 Linux 和用戶的界面並不受到影響。
應用程序的優點 — 您在 zSeries 上的 Linux 中的 Linux/UNIX 應用程序使您能訪問存儲在 zSeries 環境中的企業數據（後端集成）。這樣提高了響應速度，減少了不必要的數據復制。zSeries 出眾的容量、可伸縮性、可靠性、可用性和安全性使之成為企業伺服器應用程序的完美部署平台。另外，在商務環境中，zSeries 上的 Linux 減少了伺服器的數量，從而簡化操作並降低成本。
zSeries 上的 Linux 移植提示和技巧
這些提示和技巧是由一個 IBM 技術小組總結的，該小組負責把應用程序移植到 zSeries 上的 Linux。該文檔的全文可從 ibm.com/servers/esdd/articles/linux_s390/index.html 獲得。
小尾數法到大尾數法
S/390 是大尾數法系統。如果代碼要處理由小尾數法系統上產生的面向位元組的數據，那麼這些代碼可能需要某種位元組對換。這些數據可能需要被重新生成，如果這不可能（例如，共享的文件），那麼，應用程序需被修改，以適合處理小尾數法數據。如果原來的平台是大尾數法平台（例如 UltraSPARC、IBM ~ pSeries™……），那麼就不存在這個問題。
匯編代碼
匯編代碼需用 S/390 匯編器重寫。所有的操作碼需改成 S/390 操作碼。如果應用程序代碼使用匯編頭文件，那麼就需要該頭文件的 S/390 版本。S/390 匯編代碼的 Linux 版本使用 S/390 操作碼但遵守 GNU 匯編器的語法約定。您可以從 www.gnu.org/manual/gas-2.9.1/as.html 下載 GNU 匯編器手冊。
絕對地址和高階位
出於各種目的，一些應用程序使用硬編碼地址。一個可能的目的是在內存中定義固定的頁，用於分配或用 mmap() 來內存映射。mmap() 調用的一種形式允許頁固定。在這種模式中，mmap() 試圖使用在所請求的地址的存儲器來內存映射。在 Intel 平台上，這個地址可能被指定在 zSeries 上的 Linux 無法使用的地方。
每個平台很可能選擇不同的程序堆棧位置、系統庫、堆等等，所以在移植到其它系統的時候，硬編碼地址往往是糟糕的選擇。zSeries 定址方式還忽略高階位，所以硬編碼地址 0x80000000（高階位是 1）將被轉換成 0x00000000，而這是 zSeries 上的保留地址。在生成地址時，對地址的算術運算也能使高階位變為 1。
如果應用程序因使用絕對地址而產生段違例或其它錯誤，那麼必須修改它。/proc//map 顯示一個活動的進程是怎樣使用它的定址空間內的存儲范圍的。如果代碼必須使用絕對地址，那麼這個 map 可被用來查找還未被保留的地址范圍。
某些地址欄位的高階位可能要用「AND」來變為 0（31 位模式位）。如果該地址被用於算術運算，那麼您必須這樣做。
應用程序開發工具
部署應用程序要求在目標伺服器上有一套健壯的工具。在 ibm.com/servers/eserver/zseries/os/linux/ldt/ 的 Web 站點描述了將部署到 zSeries 上的 Linux 的 C/C++ 應用程序的開發或移植的幾個階段並給出在每個階段中有用的工具列表。
雜項
ptrace 和返回結構 — ptrace 和返回結構的使用與體系結構相關。
Configuration/build/Makefile 腳本或文件 — 很可能需要增加對 S/390 平台的支持。
proc 文件系統 — 有些區別，例如：
/proc/cpuinfo 格式不同
/proc/interrupts 未被實現
/proc/stat 不包含 INTR 信息
char 是無符號的 — 在 zSeries 上，字元類型 char 被預設地解釋為無符號的 char，而在其它平台上，char 被解釋為有符號的 char。
Va_args — 在 Linux 的 zSeries 版本中，va_list 的定義與其它平台的不同。如果您的應用程序簡單地使用一個 C 賦值語句來復制 va_list，那麼在 Linux 的 zSeries 版本中，您必須換用 _va_ 宏來復制。
㈥ linux共享內存和mmap的區別
共享內存的創建
根據理論：
1. 共享內存允許兩個或多個進程共享一給定的存儲區，因為數據不需要來回復制，所以是最快的一種進程間通信機制。共享內存可以通過mmap()映射普通文件（特殊情況下還可以採用匿名映射）機制實現，也可以通過系統V共享內存機制實現。應用介面和原理很簡單，內部機制復雜。為了實現更安全通信，往往還與信號燈等同步機制共同使用。
mmap的機制如：就是在磁碟上建立一個文件，每個進程存儲器裡面，單獨開辟一個空間來進行映射。如果多進程的話，那麼不會對實際的物理存儲器（主存）消耗太大。
shm的機制：每個進程的共享內存都直接映射到實際物理存儲器裡面。
結論：
1、mmap保存到實際硬碟，實際存儲並沒有反映到主存上。優點：儲存量可以很大（多於主存）（這里一個問題，需要高手解答,會不會太多拷貝到主存裡面？？？）；缺點：進程間讀取和寫入速度要比主存的要慢。
2、shm保存到物理存儲器（主存），實際的儲存量直接反映到主存上。優點，進程間訪問速度（讀寫）比磁碟要快；缺點，儲存量不能非常大（多於主存）
使用上看：如果分配的存儲量不大，那麼使用shm；如果存儲量大，那麼使用shm。
參看網路：http://ke..com/view/1499209.htm
mmap就是一個文件操作
看這些網路的描述：
mmap()系統調用使得進程之間通過映射同一個普通文件實現共享內存。普通文件被映射到進程地址空間後，進程可以向訪問普通內存一樣對文件進行訪問，不必再調用read()，write（）等操作。 成功執行時，mmap()返回被映射區的指針，munmap()返回0。失敗時，mmap()返回MAP_FAILED[其值為(void *)-1]，munmap返回-1。errno被設為以下的某個值 EACCES：訪問出錯EAGAIN：文件已被鎖定，或者太多的內存已被鎖定EBADF：fd不是有效的文件描述詞EINVAL：一個或者多個參數無效 ENFILE：已達到系統對打開文件的限制ENODEV：指定文件所在的文件系統不支持內存映射ENOMEM：內存不足，或者進程已超出最大內存映射數量 EPERM：權能不足，操作不允許ETXTBSY：已寫的方式打開文件，同時指定MAP_DENYWRITE標志SIGSEGV：試著向只讀區寫入 SIGBUS：試著訪問不屬於進程的內存區參數fd為即將映射到進程空間的文件描述字，
一般由open()返回，同時，fd可以指定為-1，此時須指定 flags參數中的MAP_ANON，表明進行的是匿名映射（不涉及具體的文件名，避免了文件的創建及打開，很顯然只能用於具有親緣關系的進程間通信）
相關文章參考：
mmap函數是unix/linux下的系統調用，來看《Unix Netword programming》卷二12.2節有詳細介紹。
mmap系統調用並不是完全為了用於共享內存而設計的。它本身提供了不同於一般對普通文件的訪問方式，進程可以像讀寫內存一樣對普通文件的操作。而Posix或系統V的共享內存IPC則純粹用於共享目的，當然mmap()實現共享內存也是其主要應用之一。
mmap系統調用使得進程之間通過映射同一個普通文件實現共享內存。普通文件被映射到進程地址空間後，進程可以像訪問普通內存一樣對文件進行訪問，不必再 調用read()，write（）等操作。mmap並不分配空間, 只是將文件映射到調用進程的地址空間里, 然後你就可以用memcpy等操作寫文件, 而不用write()了.寫完後用msync()同步一下, 你所寫的內容就保存到文件里了. 不過這種方式沒辦法增加文件的長度, 因為要映射的長度在調用mmap()的時候就決定了.
簡單說就是把一個文件的內容在內存裡面做一個映像，內存比磁碟快些。
基本上它是把一個檔案對應到你的virtual memory 中的一段，並傳回一個指針。
重寫總結：
1、mmap實際就是操作「文件」。
2、映射文件，除了主存的考慮外。shm的內存共享，效率應該比mmap效率要高（mmap通過io和文件操作，或「需要寫完後用msync()同步一下」）；當然mmap映射操作文件，比直接操作文件要快些;由於多了一步msync應該可以說比shm要慢了吧？？？
3、另一方面，mmap的優點是，操作比shm簡單（沒有調用比shm函數復雜），我想這也是許多人喜歡用的原因，包括nginx。
缺點，還得通過實際程序測試，確定！！！
修正理解（這也真是的，這個網站沒辦法附加；只能重寫了）：
今天又細心研究了一下，發現網路這么一段說明：
2、系統調用mmap()用於共享內存的兩種方式：
（1）使用普通文件提供的內存映射：適用於任何進程之間；此時，需要打開或創建一個文件，然後再調用mmap()；典型調用代碼如下：
fd=open(name, flag, mode);
if(fd<0)
...
ptr=mmap(NULL, len , PROT_READ|PROT_WRITE, MAP_SHARED , fd , 0); 通過mmap()實現共享內存的通信方式有許多特點和要注意的地方，我們將在範例中進行具體說明。
（2）使用特殊文件提供匿名內存映射：適用於具有親緣關系的進程之間；由於父子進程特殊的親緣關系，在父進程中先調用mmap()，然後調用fork()。那麼在調用fork()之後，子進程繼承父進程匿名映射後的地址空間，同樣也繼承mmap()返回的地址，這樣，父子進程就可以通過映射區域進行通信了。注意，這里不是一般的繼承關系。一般來說，子進程單獨維護從父進程繼承下來的一些變數。而mmap()返回的地址，卻由父子進程共同維護。
看了一下windows「內存映射文件」：http://ke..com/view/394293.htm
內存映射文件與虛擬內存有些類似，通過內存映射文件可以保留一個地址空間的區域，同時將物理存儲器提交給此區域，只是內存文件映射的物理存儲器來自一個已經存在於磁碟上的文件，而非系統的頁文件，而且在對該文件進行操作之前必須首先對文件進行映射，就如同將整個文件從磁碟載入到內存。由此可以看出，使用內存映射文件處理存儲於磁碟上的文件時，將不必再對文件執行I/O操作，這意味著在對文件進行處理時將不必再為文件申請並分配緩存，所有的文件緩存操作均由系統直接管理，由於取消了將文件數據載入到內存、數據從內存到文件的回寫以及釋放內存塊等步驟，使得內存映射文件在處理大數據量的文件時能起到相當重要的作用。另外，實際工程中的系統往往需要在多個進程之間共享數據，如果數據量小，處理方法是靈活多變的，如果共享數據容量巨大，那麼就需要藉助於內存映射文件來進行。實際上，內存映射文件正是解決本地多個進程間數據共享的最有效方法。
這里再總結一次：
1、mmap有兩種方式，一種是映射內存，它把普通文件映射為實際物理內存頁，訪問它就和訪問物理內存一樣（這也就和shm的功能一樣了）（同時不用刷新到文件）
2、mmap可以映射文件，不確定會不會像windows「內存映射文件」一樣的功能，如果是，那麼他就能映射好幾G甚至好幾百G的內存數據，對大數據處理將提供強大功能了？？？
3、shm只做內存映射，和mmap第一個功能一樣！只不過不是普通文件而已，但都是物理內存。